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Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information 
between independently created programs and other programs (including this one) and (ii) the mutual use of the information 
which has been exchanged, should contact the software interoperability coordinator. Such information may be available, 
subject to appropriate terms and conditions, including in some cases, payment of a fee. 


Address your questions to: 


IBM Corporation 

Software Interoperability Coordinator 
3605 Highway 52 N 

Rochester, MN 55901-7829 USA 


This publication could contain technical inaccuracies or typographical errors. 


This publication may refer to products that are announced but not currently available in your country. This publication may also 
refer to products that have not been announced in your country. IBM makes no commitment to make available any unan- 
nounced products referred to herein. The final decision to announce any product is based on IBM's business and technical 
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This publication contains examples of data and reports used in daily business operations. To illustrate them as completely as 
possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious 
and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. 


This publication contains small programs that are furnished by IBM as simple examples to provide an illustration. These exam- 
ples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, 
or function of these programs. All programs contained herein are provided to you "AS IS". THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. 
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This programming book is intended to help application programmers write communications programs that use the intersystem 
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use the services of ICF. ICF contains no programming interfaces for customers. 
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About ICF Programming, SC41-5442 


This book contains programming information for writing appli- 
cation programs that use the intersystem communications 
function (ICF). 


Prerequisite and Related Information 


For information about other AS/400 publications (except 


For a list of publications related to this book, see the Bibli- Advanced 36), see either of the following: 


ography. ¢ The Publications Reference book, SC41-5003, in the 
AS/400 Softcopy Library. 
e The AS/400 Information Directory, a unique, multimedia 


Who Should Use This Book interface to a searchable database that contains 
descriptions of titles available from IBM or from selected 

This book is intended primarily for AS/400 system and other publishers. The AS/400 Information Directory is 

remote system application programmers who write commu- shipped with the OS/400 operating system at no charge. 


nications programs that use ICF. 


To work with the information in this book, you should have Information Available on the World Wide 
knowledge of general communications concepts. AS/400 Web 


communications concepts are covered in the AS/400 


Advanced Series Handbook. More AS/400 information is available on the World Wide 


Web. You can access this information from the AS/400 
home page, which is at the following uniform resource locator 
(URL) address: 

AS/400 system programming terminology and programming http://www.as400. ibm. com 

using the ILE C, ILE COBOL, or ILE RPG languages. 


Before using this book, you should be familiar with the fol- 
lowing information: 


Select the Information Desk, and you will be able to access a 
variety of AS/400 information topics from that page. 
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Chapter 1. Introduction to AS/400 System Communications 


This chapter describes, in general, the different sources and 
background information needed to use intersystem commu- 
nications function (ICF) communications on the IBM* AS/400 
Advanced Series* (AS/400*) system. ICF is a function of the 
operating system that allows a program to communicate 
interactively with another program or system. Detailed 
instructions are available in other books referred to in this 
chapter. 


Planning for Data Communications 


Data communications planning should already be complete. 


Installing Communications Hardware 


Communications hardware, such as modems and cables, 
must be installed before you can start running your pro- 
grams. (The exception is intrasystem communications, which 
requires no hardware installation.) However, if your hard- 
ware is not yet installed, you can read this book and begin 
writing your programs. 


Configuring Your System for Data 
Communications 


The Communications Configuration book explains how to 
configure for communications. Although you cannot run your 
application programs until the system is properly configured, 
you can read this book and begin writing your programs. 
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You need to configure the remote system to allow commu- 
nications with the AS/400 system. The Communications 
Configuration book contains configuration considerations for 
some remote systems when communicating with an AS/400 
system. 


Writing Programs that Use the Intersystem 
Communications Function (ICF) 


You can write communications programs using the Integrated 
Language Environment* (ILE*) C/400*, ILE COBOL’, and ILE 
RPG* languages. For an explanation of the communications 
application interface provided by the intersystem communica- 
tions function (ICF), read Chapter 3 through Chapter 8. You 
can then refer to Chapter 9 through Chapter 11 for program- 
ming examples that you can use to help write and run pro- 
grams on the AS/400 system. 


You also need the appropriate communications programming 
book for the communications type you are using (for 
example, the APPC Programming book), the programming 
language books for the language you plan to use, and the 
DDS Reference book. 


Operating Communications on the AS/400 
System 


To use communications on the AS/400 system, you must be 
familiar with the base operating system as well as the com- 
mands unique to communications. Refer to the System 
Operation book and the CL Reference book for information 
on the general operation of the system. 
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Chapter 2. Communications Features 


This chapter introduces the AS/400 system communications 
features, including: 


e¢ ICF communications types 

e¢ AS/400 system communications line support 
e Base operating system support 

e High-level language support 

e Additional programming support 


Intersystem Communications Function 
Communications Types 


Communications between application programs are accom- 
plished using the AS/400 system ICF and underlying support 
provided by various communications types. Several com- 
munications types are provided so that the AS/400 system 
can communicate with remote systems having different com- 
munications methods. Some of the communications 
methods are: 


e Binary synchronous communications (BSC) 


e Systems Network Architecture (SNA). Examples of SNA 
are: 


— Systems Network Architecture upline facility (SNUF) 


— Advanced program-to-program communications 
(APPC) 


— APPC over Transmission Control Protocol/Internet 
Protocol (TCP/IP) 


— Finance communications 
— Retail communications 
e Asynchronous communications 
A communications type, designed for a specific remote 
system, makes it unnecessary to handle most system- 
dependent and protocol considerations when coding the 


AS/400 system application programs. The following commu- 
nications types are supported by ICF: 


e Advanced program-to-program communications (APPC) 
e Systems Network Architecture upline facility (SNUF) 


e Binary synchronous communications equivalence link 
(BSCEL) 


e Asynchronous communications 

e Intrasystem communications 

e Finance communications 

e Retail communications 
An AS/400 system program uses high-level language oper- 
ations and communications functions to communicate with a 
remote system through ICF. A return code, made up of 


major and minor return codes, informs the program of the 
success or failure of each operation. You can use several of 
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the communications functions and return codes with any of 
the communications types. You can use some functions and 
return codes with only one or two communications types. 
You can use a program written for use with one communica- 
tions type, with little or no change, to communicate with a 
different communications type. The level of change required 
in the program depends on the two communications types, 
the communications functions, and the return codes. 


Your configuration device descriptions identify the devices on 
your local system with which communications occur. Each 
communications type has a corresponding configuration 
device description of the same type. 


AS/400 System Communications Types 


The following is a description of the AS/400 system commu- 
nications types supported by ICF, including a brief overview 
of the remote systems and devices supported by each type. 


Advanced Program-to-Program Communications 
(APPC): APPC allows the system to communicate with 
other IBM and non-IBM systems that support the SNA logical 
unit type 6.2 (LU 6.2) architecture. Using APPC allows 
system functions and application programs on the system to 
communicate with other system functions or application pro- 
grams on: 


e The same system 

e Another AS/400 system 

e A System/38 

e A System/36 

e Any other system (such as CICS* with similar levels of 
APPC support. 


APPC allows AS/400 system application programs to start 
programs on remote systems, and allows remote programs 
to start programs on the AS/400 system. APPC also allows 
AS/400 system application programs to start other application 
programs on the local system. The networking capability of 
data communications support that routes data in a network 
between two or more APPC systems that do not need to be 
adjacent, called Advanced Peer-to-Peer Networking” 
(APPN*) support, is available through the APPC interface. 


An APPC conversation cannot be used by both the 
System/38 environment and the AS/400 operating environ- 
ment. A diagnostic message is sent to an application 
attempting to open an ICF file in the AS/400 operating envi- 
ronment, to accept a conversation using Common Program- 
ming Interface (CPI) Communications, or to open either a 
communications file or a mixed device file in the System/38 
environment for the same APPC conversation. Only one 
interface can be used for any conversation. 


Refer to the APPC Programming book for more information. 


APPC over TCP/IP: APPC over TCP/IP allows the 
system to communicate with other systems that support the 
SNA logical unit type 6.2 (LU 6.2) architecture running over 
TCP/IP. This support must be compliant with the Multipro- 
tocol Transport Networking (MPTN) architecture, such as the 
support in the IBM AnyNet* products. Refer to the Multipro- 
tocol Transport Networking (MPTN) Architecture: Technical 
Overview book, GC31-7073, for more information about 
MPTN. 


APPC programs running over TCP/IP networks should see 
little or no difference than if they ran over SNA networks. 
Therefore, information in this book that applies to APPC also 
applies to APPC over TCP/IP (unless otherwise noted). 
Some additional configuration is required for APPC over 
TCP/IP. Refer to the Communications Configuration book for 
information about configuring for APPC over TCP/IP. 


Examples of systems that support APPC over TCP/IP 
include: 


¢ Operating System/400* (OS/400*) 
¢ Operating System/2* (OS/2*) 
e Multiple Virtual Storage (MVS) 


Systems Network Architecture Upline Facility 
(SNUF): SNUF allows the system to communicate with 
CICS and Information Management System (IMS) applica- 
tions on other IBM systems. You can use SNUF to commu- 
nicate with the following host systems: 


e System/370* computer 
e¢ System/390* computer 


SNUF allows AS/400 system application programs to start 
programs on remote host systems, and allows programs on 
remote host systems to start programs on the AS/400 
system. Both interactive and batch operations are sup- 
ported. 


SNA 3270 Program Interface: The SNA 3270 program 
interface allows an AS/400 application to communicate with a 
host application by sending and receiving 3270 data streams. 


Refer to the SNA Upline Facility Programming book for more 
information. 


Binary Synchronous Communication Equivalence 
Link (BSCEL): AS/400 system BSCEL provides the fol- 
lowing: 
e Distributed data processing support to the AS/400 
system users who want to communicate with another 
system or device at a remote location using BSC. 


¢ Online and batch communications between application 
programs on different systems (such as System/38) 
using BSC. 
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¢ Communications with another AS/400 system, 
System/36, or System/34 using BSCEL. 


¢ Communications with another AS/400 system, 
System/36, or System/34, with RPG II support for tele- 
communications. 


BSCEL allows AS/400 system applications to start programs 
on remote systems that support BSCEL, and allows remote 
programs to start programs on the AS/400 system. 


Refer to the BSC Equivalence Link Programming book for 
more information. 


Asynchronous Communications: Asynchronous com- 
munications is a method of communications supported by the 
operating system that allows an exchange of data with a 
remote device, using either a start-stop line or an X.25 line. 
The system can use asynchronous communications support 
to communicate with another asynchronous communications 
location or with a packet assembler/disassembler (PAD) that 
gives the system access to an X.25 packet-switching data 
network (PSDN). The system can use X.25 support to com- 
municate directly through an X.25 network, or to emulate a 
PAD using the International Telegraph and Telephone 
Consultative Committee (CCITT) recommendations X.3, 
X.28, and X.29. 


The system can use the AS/400 system asynchronous com- 
munications support to communicate with: 


e Another AS/400 system 
e A System/36 
e Asynchronous devices 


Asynchronous communications support allows AS/400 
system application programs to start programs on remote 
systems, and allows remote programs to start programs on 
the AS/400 system. 


Refer to the Asynchronous Communications Programming 
book for more information. 


Intrasystem Communications: Intrasystem commu- 
nications allows communication between two application pro- 
grams on the same AS/400 system. A source program can 
acquire more than one session for a given device 
description, and can have more than one transaction at the 
same time. However, a source program cannot have a 
transaction with two different programs on the same session. 


Note: Intrasystem communications does not support the 
concept of a remote system or a remote program. When 
these terms are used in this book with regard to intrasystem 
communications, they refer to the program with which your 
program is communicating. 


Refer to the Intrasystem Communications Programming book 
for more information. 


Finance Communications: Finance communications 
allows you to attach 3601, 3694, 4701, 4702, 4730, 4731, 
4732, 4736, 4737, and Financial Branch System Services 
(FBSS) controllers to your AS/400 system using synchro- 
nous data link control (SDLC). SDLC is a form of commu- 
nications line control that uses commands to control the 
transfer of data over a communications line. You can also 
attach the 4701, 4702, 4737, and Financial Branch System 
Services controllers using X.25. 


Note: 4737 self-service transaction station controllers are 
configured as FBSS controllers. 


In addition, you can attach controllers configured as FBSS 
controllers using a token-ring or Ethernet local area network 
(LAN). Since these controllers do not support Ethernet net- 
works, you must use an 8209 bridge when you use an 
Ethernet configuration on the AS/400 system. 


While programs using ICF can communicate with any of the 
finance controllers, programs that do not use ICF can com- 
municate only with controllers configured as a 3694, 4701, 
and 4702 on the AS/400 system. 


Refer to the Finance Communications Programming book for 
more information. 


Retail Communications: Retail communications allows 
you to attach retail controllers (3651, 3684, 4680, 4681, 
4684, and 4692) to the AS/400 system using the SDLC pro- 
tocol. X.25 is supported for a 4684 controller, provided it has 
Retail Industry Programming Support Services (RIPSS) 3.01, 
a program that provides access to the application files on the 
4684 controller. 


Note: The 4681 controller is the double-byte character set 
(DBCS) equivalent of the 4680 controller, and the 4692 is the 
DBCS equivalent of the 4684 controller. In addition, retail 
communications allows the AS/400 system to act as an in- 
store processor in the retail environment. 


You can use the AS/400 system in several different retail 
environments: 


e Retail in-store processor environment 


You can have a host system such as a System/370 at a 
remote site with several retail controllers and terminals in 
your store. The AS/400 system can be installed in your 

store as an in-store processor to coordinate communica- 
tions between the host and the retail controllers. 


e Retail host processor environment 
The AS/400 system can also function as a host system 
to several retail controllers. 


Refer to the Retail Communications Programming book for 
more information. 


Non-Intersystem Communications 
Function Communications 


You can also run non-ICF communications on the AS/400 
system, such as the following: 


¢ 3270 device emulation and 3270 BSC application 
program interface 


e Remote job entry (RJE) 
e Finance communications 


¢ Transmission Control Protocol/Internet Protocol pro- 
grams (TCP/IP) 


¢ Common Programming Interface (CPI) Communications 
e User-defined communications 


¢ Sockets 


Because these communications functions are not part of ICF, 
they are described in other books, which are identified in the 
list of related books in the Bibliography. Refer also to the 
Publications Reference book. 


Communicating with Remote Work 
Stations 


No communications programming is required to communicate 
with remote work stations. The necessary communications 
programs are provided by the system based on the informa- 
tion provided when the remote work station is configured. 
The program interface for remote work stations is the same 
as the program interface for local work stations. Refer to the 
Application Display Programming book for information on the 
application interface to remote work stations. 


Combinations of Communications Types 


You can configure multiple communications device 
descriptions in the AS/400 system. Multiple communica- 
tions configurations, or the physical placement of commu- 
nications controllers, the attachment of communications lines, 
and so on, can be active at the same time. All active config- 
urations do not have to be of the same type. The number of 
configurations that can be active is determined by the 
number of communications lines available, and whether any 
lines are being shared by SNA-type communications. A con- 
figuration becomes active when you vary on the configura- 
tion, as described in “Varying on Communications 
Configurations” on page 3-3. 


AS/400 System Communications Line 
Support 


The AS/400 system supports the following telecommunication 
lines (all the lines do not have to be the same): 


¢ Switched point-to-point (manual or automatic answer, 
manual or automatic call) 
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e Nonswitched point-to-point 
e Nonswitched multipoint 
e¢ IBM Token-Ring Local Area Network 
e X.25 network 
e Ethernet network 
e Frame Relay 
e IDLC 
« DDI 
e Wireless 
Each ICF communications type (except intrasystem commu- 


nications) requires at least one communications line to com- 
municate with a remote system. 


Operating System/400 


Following is a description of the Operating System/400 
(OS/400) support provided for AS/400 system communica- 
tions. 


Communications Configuration 


Before you can use communications on the AS/400 system, 
you must define the environment through the communica- 
tions configuration function. This support allows you to 
create, change, display, and delete the communications 
network interface, network server, line, controller, and device 
descriptions. 


APPC/APPN support requires mode descriptions and class- 
of-service descriptions. The configuration support provides 
this function. 


An integrated services digital network (ISDN), which is a 
network that can provide voice, data, and image over the 
same communications line, requires network interface 
descriptions and connection lists. The configuration support 
provides this function. 


A File Server I/O Processor (FSIOP), which is an 
input/output processor (IOP) that serves files, requires a 
network server description. 


Refer to the Communications Configuration book for more 
information on communications configuration. APPN support 
provides the ability to communicate with a remote system 
without having to manually configure the remote system. 
Refer to the APPN Support book for more information. 
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Intersystem Communications Function File 


The ICF file is used to send and receive data between two 
application programs, and to describe how to present that 
data. The ICF file contains the file description identifying the 
record formats used by the communications application 
program. 


The ICF file allows you to define a single file and the 
program devices used by that file. An ICF file supports any 
combination of program devices for all the supported commu- 
nications types. The application program can then write data 
to or receive data from any of the program devices defined in 
the file. 


Refer to Chapter 4 for information on creating and using the 
ICF file. 


Data Description Specifications (DDS) 


DDS defines the format of the data and the characteristics of 
the operation used on the data. This information is specified 
as part of the ICF file, the display file, and the printer file. 


Certain DDS functions are unique to communications. These 
functions are described in Chapter 6. (For general informa- 
tion on coding DDS, refer to the DDS Reference book.) 


System-Supplied Formats 

System-supplied formats that provide functions similar to 
those accomplished by using DDS keywords are provided as 
part of the ICF support, and can be used to do specific com- 
munications functions. Refer to Chapter 7 for more informa- 
tion about system-supplied formats. 


Control Language 


With control language (CL) commands, you can create, 
change, display, and delete the various communications con- 
figurations. A menu interface is also provided to assist you 
in this function. 


ICF file commands are provided that allow you to create, 
change, and override the file descriptions. Commands are 
also provided that allow you to add, change, remove or over- 
ride device entries for the file. Chapter 4 describes the file 
commands and their use. 


You cannot use CL commands to do ICF communications 
functions. 


For more information on the CL commands for configuring 
communications, refer to the Communications Configuration 
book. 


Security 


The security provided on the AS/400 system controls who 
can use communications device descriptions, and the com- 
mands that are used with the device descriptions. Security 
on both the local and remote systems must be considered in 
writing and running applications. 


See the Security — Reference book for general system secu- 
rity information and Chapter 8 for communications-specific 
security considerations. 


Error Handling 


Major and minor return codes are provided to the application 
program so that error conditions can be properly handled. 
Applications written in the ILE C, ILE COBOL, and ILE RPG 
programming languages can access the return codes to help 
diagnose problems. In addition, messages are entered in the 
job log to identify the error that occurred. The ILE COBOL 
and ILE RPG programming languages provide language- 
defined file status that can be used either in place of, or in 
addition to, the major and minor return code. The ILE C pro- 
gramming language does not have file status values. 


You can recover from many communications errors with little 
or no operator involvement. You may be able to reestablish 
the session or close and reopen the file to accomplish 


recovery within the user program. The Communications 
Management book describes line errors. 
Appendix B discusses program error recovery. 


High-Level Language Support 


You can use AS/400 system communications support to write 
application programs in the supported high-level languages. 


The ILE C, ILE COBOL, and ILE RPG programming lan- 
guages support the ICF interface. Chapter 9 through 
Chapter 11 provide program examples written in the ILE C, 
COBOL/400, and RPG/400 languages. 


The programs presented in this book serve as examples 
only. They are used to show concepts and techniques and 
may not represent the most efficient programming methods. 


Additional Programming Support 


Support is also provided in addition to the ICF interface to 
allow the application program to send or retrieve database 
file members from one system to another. This support is 
provided by file transfer support (FTS). 


Appendix E describes this support. 
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Chapter 3. Introduction to Intersystem Communications Function 


ICF allows program-to-program communications between the 
AS/400 system and other systems. It also provides program- 
to-device communications between the AS/400 system and 
hardware devices. 


This chapter provides an introduction to: 


¢ How ICF works 

¢ Some of the terms used to describe ICF 

¢ Configuring for and starting communications 
¢ Defining your ICF file 

¢ How to write a program to use ICF 


Notes: 


1. The two examples shown in this chapter allow two 
AS/400 systems to communicate with each other. One 
program is started by the local AS/400 system operator; 
this program then starts the program on the remote 
AS/400 system. 


2. Although communications types in these examples are 
advanced program-to-program communications (APPC) 
and binary synchronous communications equivalence 
link (BSCEL), the examples provide a general under- 
standing of how to write a program that uses any com- 
munications type under ICF. 


Local 
AS/400 System 
Local 
Application 
Program 
Send Receive 
Data Link 
f 
Data Flow 


Figure 3-1. Sending Data from a Local Program to a Remote Program 
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3. Not all communications types require all the operations 
shown in this chapter. Refer to the appropriate commu- 
nications programming book for the communications 
type you are using for information about a specific com- 
munications type. 


In Figure 3-1, an application program on the local AS/400 
system (local program) sends data to an application program 
on a remote AS/400 system (remote program) and then 
receives data. 


Either program can send data first. You must determine 
which system is to send data first before you write a 
program, so you know which operations to do first. Use ICF 
communications functions and high-level language operations 
to handle communications within an application program. 
The ICF functions are described in Chapter 6 and 

Chapter 7. The language operations you use are the same 
operations you use when your program is not using ICF. 
Although these operations are summarized in Chapter 9 
through Chapter 11, they are not fully described in this book. 
Refer to the appropriate language reference book for more 
information. 
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Figure 3-2. Major Parts of ICF Data Management 


Figure 3-2 shows the major parts of ICF. The local applica- 
tion program is the program you write to allow your system 
to communicate with a remote system. ICF data manage- 
ment handles the communications functions and data from 
your program. The underlying support provided by the com- 
munications type handles the communications protocol 
needed to connect your AS/400 system to the remote 
system. 


ICF data management supports several communications 
types. Use the communications type that enables you to 
communicate with your remote system. Refer to Chapter 2 
for a list of the communications types and for an overview of 
the remote systems they support. See the appropriate com- 
munications programming book for a complete description of 
the remote systems supported by a specific communications 
type. 


Hardware and system-supplied programs handle sending and 
receiving data on the communications line. Since you do not 
need to know about these system programs to write an appli- 
cation program using ICF, these programs and hardware are 
not described in this book. 
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Configuring for Communications 


Before communications can occur between two systems, 
both systems must be configured. You must configure your 
system to define the appropriate communications hardware 
and characteristics before you can use your programs. The 
AS/400 system communications configuration support allows 
you to create, change, delete, display, and print the following 
configuration objects: 


e Line descriptions 

¢ Controller descriptions 

e Device descriptions 

e Mode descriptions 

¢ Class-of-service descriptions 
e Network interface descriptions 
e Network server descriptions 

¢ Connection lists 

¢ Configuration lists 


Not all of the listed configurations are used by all the com- 
munications types. 


Part of the connection between the application and configura- 
tion is through the remote location name that is defined as 
part of the device description. Refer to “The Intersystem 
Communications Function File” for more information on how 
this connection is made. 


If programs on your system can be started from a remote 
system, you can define the distribution of work across your 
subsystems. The AS/400 system considers the communica- 
tions device to be another source of work for a subsystem. 
Therefore, you must define a communications entry within 
the subsystem description to identify the communications 
devices for which work can be received by the subsystem. 


Default communications entries are shipped with the system. 
However, you can change these entries with the Add, 
Change, and Remove Communications Entry (ADDCMNE, 
CHGCMNE, and RMVCMNE) commands. Refer to the Com- 
munications Management book for more information on using 
these commands. Refer to the Work Management book for 
information on subsystems and communications entries. 


Varying on Communications 
Configurations 


You must vary on the particular communications configura- 
tions you want to use before running your communications 
applications. (The configurations must already be defined.) 
The Vary Configuration (VRYCFG) command is used to vary 
on the appropriate network interface, line, controller, network 
server, and device descriptions. 


Note: You can specify that the configurations be automat- 
ically varied on at IPL when you create your configurations. 


The VRYCFG command does the following: 


e Ensures compatibility between the configuration and the 
communications hardware 


e Determines whether the requested data link is available 


e Establishes a physical connection with the remote 
system 


Note: For SNA configurations, SNA communications 
may be established with the remote system, depending 
on the line type (switched or nonswitched) and the con- 
figuration parameters you have chosen. 


The VRYCFG command prepares only the local end of the 
link to communicate with the remote system. You must also 
prepare the remote system. Communication can begin when 
you have prepared both ends and have established a phys- 
ical connection between the two. For APPC communica- 
tions, a mode must be started before you establish a 
session. Generally, the mode starts automatically when the 
device is varied on or when a request to establish a session 
is received. You can also use the Start Mode (STRMOD) 
command to start a mode. 


Refer to the Communications Management book for more 
information on the VRYCFG command on starting modes. 


The Intersystem Communications Function 
File 


An ICF device file defines the layout of the data sent and 
received between two application programs and links you to 
the configuration objects that you will use to communicate 
with the remote system. You identify and use this file in your 
high-level language application. 


Defining the File 


The following commands are used to define the file: 


e The Create Intersystem Communications Function File 
(CRTICFF) command is used to create the ICF file. 


Note: If you use system-supplied formats (described in 
Chapter 7), IBM supplies a file called QICDMF for your 
use and you do not need to do this step. 


e The Add Intersystem Communications Function Device 
Entry (ADDICFDEVE) or Override Intersystem Commu- 
nications Function Device Entry (OVRICFDEVE) 
command is used to define a program device entry. 

This program device entry is that part of the file that pro- 
vides the connection to the configuration objects that you 
will use to communicate with the remote system. 


Using the File 


An application program uses the file as follows: 


e A program communicates through a program device 
name. The program device name used in the applica- 
tion maps you to the program device entry in the ICF file 
that contains the same program device name. 


e The program device entry also contains a remote 
location name. This remote location name (specified as 
part of the device description) provides the final step in 
completing the link between the application and the 
device description. 


Refer to Chapter 4 for more information on creating the ICF 
file and on defining program device entries to the ICF file. 
Also refer to Chapter 4 for more information on the remote 
location name. 


Figure 3-3 on page 3-4 shows the relationship between the 
program, the ICF file, and the communications configura- 
tions. 


Not all of the communications types require that all of these 
configurations be explicitly created. Also note that the 
network interface description is only required when communi- 
cating across an ISDN. 
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Figure 3-3. ICF File-Configuration Relationship 
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Starting Your Program 


Your application program can be started by an operator at 
your system, or by a request from the remote system. 


A remote system starts an application program on your local 
AS/400 system by sending a special record, called a 
program start request, to your system. Refer to “Starting a 
Program on the Remote System” on page 3-6 for more infor- 
mation about the program start request. Refer to the appro- 
priate communications programming book for the 
communications type you are using for a description of this 
special record. 


Opening the Intersystem Communications 
Function File 


Before communications can occur, your program must open 


an ICF file (previously created with the CRTICFF command). 
All communications functions are issued through the ICF file. 
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Starting Communications with the Remote 
System 


Before your local program can communicate with the remote 
system, you must establish a communications session. A 
communications session is a logical connection between two 
systems through which a local program can communicate 
with a program at a remote location. A communications 
session is established with an acquire operation and is 
ended with a release operation or end-of-session function. 


In Figure 3-4 on page 3-5, your program establishes a 
session using an acquire operation with PGMDEVA specified 
as the program device name. 


The program device name specified on an acquire operation 
must correspond to a program device entry in the ICF file 
with the same program device name. The remote location 
name associated with that program device entry identifies the 
remote system with which the session is to be established. 


The program device entry is defined with the ADDICFDEVE 

or OVRICFDEVE command. The PGMDEV parameter spec- 
ifies the program device name. The RMTLOCNAME param- 
eter specifies the remote location name. The remote location 


name (also specified as part of the device description) pro- 
vides the link between the program device entry and the 
device description. 
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Local 
Program 
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-—___ Return 
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Support 


Remote 
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Data 
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Figure 3-4. Establishing a Session 


The following is an example of how a control language 
program and a high-level language application program are 
used to acquire a program device. You can use either the 
ADDICFDEVE or OVRICFDEVE command. This example 
uses the ADDICFDEVE command. 
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YOURCL 


ADDICFDEVE FILE(ICFFILE) PGMDEV(PGMDEVA) = RMTLOCNAME (CHICAGO) 
| 


| Identifies the remote 
| location with which 

| your program will 

| communicate. 


Identifies the name known 
by the program (PGMDEVA) . 


Identifies the ICF file 
to which the definition is added. 


CALL YOURPROG 


YOURPROG 


OPEN ICFFILE 


ACQUIRE PGMDEVA 


Note: You can use other parameters with the 

ADDICFDEVE and OVRICFDEVE commands to define attri- 
butes, such as format selection (FMTSLT), to be used during 
this session. See Chapter 4 for more information about the 
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ADDICFDEVE and OVRICFDEVE commands and their 
parameters. 


When the program issues an acquire operation, ICF data 
management returns a return code to your program indi- 
cating whether it can communicate (whether a session is 
established) with the remote system at this time. If commu- 
nications cannot be established, the return code tells your 


program why communications failed. See Appendix B for 
more information about return codes. 


Your program cannot send or receive data until the acquire 
operation succeeds. Therefore, your program must check 
the return code. In our example, the return code indicates 
that communications was started. Therefore, a communica- 
tions session exists between the local AS/400 system and 
the remote AS/400 system, as shown in Figure 3-5. 


Local Remote 
AS/400 System AS/400 System 
Local 
Program 
/\ 
pre Sees =. _eernntinteaiane 
Session 
ICF ICF 
Data Data 
Management Management 
V 
Communications Communications 
Support < Support 
> 
Data Link 


Figure 3-5. Communications Session Established 


The acquire can be done automatically as a part of the open 
file operation by specifying the desired program device name 
(in this example PGMDEVA) on the ACQPGMDEV param- 
eter of the CRTICFF command. Refer to Chapter 4 for more 
information. 


Even though the session has been started, the application 
program at the remote system has not yet started. “Starting 
a Program on the Remote System” describes how an appli- 
cation program is started at the remote system. 


Starting a Program on the Remote System 


Your program must specify and start the program at the 
remote system with which it will communicate. After this 
remote program has been started, a communications trans- 
action has been started. A communications transaction is a 
logical connection between two programs on a session. A 
communications transaction is started by an evoke function 
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and is ended by a detach function. After the communications 
transaction starts, data can be exchanged between the two 
programs. 


Use the evoke function with the necessary parameters to 
send the name of the program that you want started at the 
remote system. These parameters include the program 
name (from either a high-level language program or a control 
language program), the remote system library where the 
program is stored, and security information (when required). 
When your program issues a write operation with the evoke 
function specified, a program start request is sent to the 
remote system. 


The program that issues the evoke function is the source 
program. The program started on the remote system is the 
target program. In this example, the local program is the 
source program (it issued the evoke), and the remote 
program is the target program. 


In Figure 3-6 on page 3-7, the evoke function is used to 
start the program named TGTPGM at the remote system. 


Local 
AS/400 System 


Remote 
AS/400 System 


Data Link 


Figure 3-6. Program Started at Remote System by Evoke Function 


A return code is always given to your program to indicate the 
status of the evoke function unless the program start request 
is delayed by use of the DFREVOKE keyword. In 

Figure 3-6, the return code tells your program that the evoke 
request was accepted and a program start request was sent 
to the remote system. If the program start request succeeds, 
the remote system program and the communications trans- 
action start. 


Your program can also send program initialization parame- 
ters with the evoke function. If the remote system is an 
AS/400 system, the target program can access any parame- 
ters specified with the evoke as if they were parameters 
passed on a call command. 


The type of evoke function you use depends on the commu- 
nications type you use and on the type of remote system 
with which you communicate. For more information about 
the evoke functions, refer to Chapter 6, Chapter 7, and to 
the appropriate communications programming book for the 
communications type you are using. 


Source Target 
Program Program 
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Communications 
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|__ Return 
Code 
ICF ICF 
Data Data 
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Program 
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97 ; Request 7 
Communications Communications 
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Connecting to the Session — Target 
Program 


Before a target program can send or receive data, it must 
first be associated with the session in which the program 
start request was received. This association is established 
by opening an ICF file and acquiring a program device asso- 
ciated with a special remote location name of *REQUESTER. 


A remote location name of *REQUESTER specifies that: 


e The remote location used is the remote location speci- 
fied in the device description that received the program 
start request. 


e There is no specific remote location assigned to the 
program device by the ADDICFDEVE or the 
OVRICFDEVE command. 


Any program device name defined in a program device entry 
with a remote location name of *REQUESTER is referred to 
as a requesting program device. 


The target program identifies the requesting program device 
in the same way that the source program does. The target 
program specifies, on an acquire operation, the same 
program device name as the name specified on the 
PGMDEV parameter on the ADDICFDEVE or the 
OVRICFDEVE command. 
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Remote Location 
Name ----------- cial (Ga cae aa SL > 
(*REQUESTER) 


Remote Location Name 


Controller Description 


Line Description 


Figure 3-7. Requesting Program Device Relationship 


Figure 3-7 on page 3-8 shows the relationship between the 
program, the ICF file, and the communications configurations 
for a requesting program device. 


Note: The device description that receives the program start 
request is the device description that is selected when the 
acquire operation is issued to the requesting program device. 


When the target program issues an acquire operation to the 
requesting program device, a new session does not start. 
The acquire only establishes a logical connection between 
the target program and the session and transaction that were 
started by the source program. 


The remote program cannot send or receive data until the 
acquire operation is successful. 


The following shows how a control language program and 
high-level language application program can be used to 
acquire a requesting program device. 
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TGTCLPGM 


OVRICFDEVE PGMDEV(PGMDEVB) = RMTLOCNAME (*REQUESTER) 


| | 

| Identifies that you want to 

| communicate with the device 

| description that receives the 
| program start request. 


Identifies the name known 
by the program (PGMDEVB) . 
CALL TGTPGM 


TGTPGM 


OPEN ICFFILE 


ACQUIRE PGMDEVB 


Note: The target program started as a result of a program 
start request can be a high-level language program or a 
control language (CL) program. In this example, the CL 
program containing the OVRICFDEVE command and the call 
statement is the program that is started as a result of the 
program start request. The CL program calls the high-level 
language program. In Figure 3-8 on page 3-9, the target 
program establishes a logical connection to the session and 
transaction (started by the source program) by acquiring the 


requesting program device named PGMDEVB (as assigned 
by the ADDICFDEVE or OVRICFDEVE command). 


Local Remote 
AS/400 System AS/400 System 
Source Target 
Program Program 
Acquire 
PGMDEVB 
‘\ 
ICF ICF 
Data Data 
Management Management 
V 
Communications Communications 
Support x Support 
> 
Data Link 


Figure 3-8. Establishing a Logical Connection between the Target Program and the Session 


The acquire can be done automatically as part of the open 
file operation, by specifying the requesting program device 
name (in this example, PGMDEVB) on the ACQPGMDEV 
parameter of the CRTICFF command. Refer to Chapter 4 
for more information. 


Sending and Receiving Data request. 


In Figure 3-9 on page 3-10, the source program sends data 
first. To obtain that data, the target program must issue a 
receive request as the first operation following the acquire. 


You use the same program device name specified on the 
acquire operation on each send and receive request. In the 


Chapter 3. Introduction to Intersystem Communications Function 


Return 
Code 
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example, the source program uses the program device name 
PGMDEVA and the target program uses PGMDEVB. 


Again, the source program gets a return code indicating the 
status of the send request. Since the remote system in this 
example is an AS/400 system, the target program is also 
given a return code indicating the status of the receive 
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Figure 3-9. Data Sent by a Send Request 


Ending Communications with the Remote 
System 


You must end both the communications transaction and the 
communications session to end communications with the 
remote system. You can end the communications session in 
one of the following two ways: 


e Explicitly by the program, as shown in Figure 3-10 on 
page 3-11 and Figure 3-11 on page 3-12 


¢ Implicitly ending all sessions and transactions associated 
with the source program by a close of the ICF file 


The transaction and session can be ended by either the 
source or target program. 


Ending the Transaction 


The sending and receiving of data continues until one of the 
two programs ends the communications transaction (either 
the source or target program can end the transaction). The 
detach function is used to tell the remote program that your 
program has no more data to send and has ended the com- 
munications transaction. 
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Figure 3-10 on page 3-11 shows the source program issuing 
a detach function to end the communication transaction. 


In this example, the target program is given a return code 
indicating that the transaction has ended. The target 
program can continue or end processing, but it can no longer 
communicate with the source program. However, the target 
program must end the logical connection to the session by 
ending the session. 


The communications session still exists for the source 
program. The source program can start another program at 
the remote system and another transaction, or it can end the 
communications session and stop communicating with the 
remote system. 


If a target program issues the detach, its logical connection 
to the session as well as the transaction is ended. 


Local 
AS/400 System 


Remote 
AS/400 System 


Figure 3-10. Ending a Communications Transaction: Detach Function 
Ending the Session 


When a session is no longer needed, it should be ended. A 
source program ends the session by issuing a release opera- 
tion or end-of-session function. However, a target program 
must also sever the connection to the session by issuing a 
release operation or end-of-session function. 


Figure 3-11 on page 3-12 shows the source program using 
the release operation and the target program using an end- 
of-session function to end the session. 


When the source program issues the release operation, ICF 
data management tries to end the session. If the commu- 
nications transaction has ended, the session ends and the 
source program receives a return code indicating that the 
session has ended. 


If the session cannot be ended, the source program receives 
a return code indicating that the release operation was not 
successful. (For example, the transaction may not have 
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ended.) If your program cannot recover from the error, you 
can use the end-of-session function to force the session to 
end. The end-of-session function always ends the session. 


If you issue an end-of-session, you may not be able to deter- 
mine: 

e If the transaction has ended normally 

e If all the data has been sent or received 


Note: When you use the end-of-session function, your 
program must make sure all data is received. 


The program at the remote system may (depending on the 
communications type) receive a return code indicating that 
the session did not end normally. 


After ending the transaction and session, a source program 
can start another session and transaction, continue local pro- 
cessing, or end. 


A target program can continue local processing or end after 
ending a session. 
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Figure 3-11. Ending a Session: Release Operation and End-of-Session Function 


Closing the Intersystem Communications 
Function File 


Your program should close the ICF file when you are done 
processing. Closing the ICF file also implicitly ends any 
active transactions or sessions for the program. 


Varying off Communications 
Configurations 


When you no longer need a communications configuration, 
you can use the Vary Configuration (VRYCFG) command to 
vary off the configurations you previously varied on. 


If you are using an APPC device, you can end any active 
modes with the End Mode (ENDMOD) command before you 
use the VRYCFG command. If you do not use the ENDMOD 
command, any active modes associated with the device are 
ended automatically as part of the VRYCFG. 
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Refer to the Communications Management book for informa- 
tion on the VRYCFG and ENDMOD commands. 


Additional Information on Sessions and 
Transactions 


The information presented in this chapter has only described 
the flow of two programs using a single session and trans- 
action to communicate with each other. 


The following sections describe variations of sessions and 
transactions. 
Multiple Transactions 


Figure 3-12 on page 3-13 shows how a source program on 
a single session can start and end multiple transactions. 
Only one transaction can be active on a session at a time. 
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Figure 3-12. Starting and Ending Sessions and Transactions 


Ey = Program A, on the local AS/400 system, opens the ICF 
file and then issues an acquire operation to start a 
session with the remote AS/400 system. 


HZ _sProgram A issues the evoke function, which starts the 
communications transaction, to start Program B on the 
remote AS/400 system. 


Program B must open the ICF file on the remote 
AS/400 system and issue an acquire operation for the 
requesting program device to establish a logical con- 
nection to the session and transaction. 


Ey “Programs A and B exchange data. Program A ends 
the transaction. Program B can end (as shown) or 
continue processing. Program B cannot, however, 
communicate with the local AS/400 system. 


Ey“ Program B releases the session it previously acquired 
and closes the ICF file. 


Program A starts a transaction with Program C on the 
remote AS/400 system and exchanges data. 
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Program C on the remote AS/400 system ends the 
transaction. (Either program can end the communica- 
tions transaction.) Program C releases the session 
and closes the ICF file. 


Es“ Program A starts and ends another transaction with 
Program B. Program A then releases the session with 
the remote AS/400 system, and closes the file on the 
local AS/400 system. 


Multiple Sessions 


A program can communicate over multiple sessions to the 
same system or different systems, and can have all the ses- 
sions at the same time. When a program is communicating 
over multiple sessions, it can be both a target and a source 
program, but it cannot be both on the same session. 


A program started by a program start request is the target 
program for that session. However, this program can also 
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become a source program by establishing a session with 
another remote system. Figure 3-13 on page 3-14 shows 
how a target program can start a session and a transaction. 


Ey = Program A, on the local AS/400 system, opens the ICF 6 | 
file and then issues an acquire operation to start a 
session with the remote AS/400 system. 


1s Program A uses the evoke function to start Program B 
on the remote AS/400 system-I, which starts a commu- 
nications transaction. 


Program B must open the ICF file and issue an acquire 8 
operation for the requesting program device to estab- 
lish a logical connection with the session and trans- 


Programs A and B can exchange data. 


Program B issues an acquire operation to start a 
session with the remote AS/400 system-ll. 


Program B uses the evoke function to start Program C 
on the remote AS/400 system-Il, which starts a com- 
munications transaction. 


Program C must open the ICF file and issue an acquire 
operation for the requesting program device to estab- 
lish a logical connection. 


Programs B and C can exchange data. 
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Figure 3-13. Remotely Started Program Starts a Session and Transaction 


Summary 


The major tasks you do to use ICF for a source program and 2 | 
a target program are explained in the following sections. 


Source Program 
4 


Figure 3-14 on page 3-15 shows the sequence of events 
your AS/400 system application program follows when it 
starts a session with the remote system. 


E¥ = You must vary on the communications configurations 
before programs can use them to communicate with a 
remote system. Use the VRYCFG command to vary 
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on the configurations. You can do the VRYCFG either 
within the application CL or interactively. 


You must start the AS/400 system application program 
(source program) that communicates with the program 
at the remote system. 


The application program must open an ICF file. 


The AS/400 system program must start a session with 
the remote system before communications can begin. 
Your program starts a session when it issues an 
acquire operation. 


When your program starts (establishes) the session 
with an acquire operation, an ADDICFDEVE or 
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Figure 3-14. The AS/400 System Application Starts a Session with a Remote System 


OVRICFDEVE command specifies the program device 
name and the remote location name (identifying the 
remote system) associated with the session. 


Note: The acquire can be done implicitly as part of 
the open operation. 


Within each session, you can start (evoke) transactions 
to allow your program to communicate with target pro- 
grams. A transaction starts when your program uses 
the evoke function to start a specified target program. 


Within each transaction, data can be sent and received 
between the source program and the target. 


Either program can end the transaction when all data 
has been sent or received. Your program uses the 
detach function to end the transaction. When the 
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remote system ends the transaction, your program 
receives a return code indicating that the transaction 
has ended. If a target program issues the detach, the 
logical connection to the session is ended implicitly by 
the detach (a release operation is not needed). 


When all transactions have ended, your program 
should end the session. Your program can end the 
session by using the release operation or the end-of- 
session function. 


Your program must close the ICF file. 


Use the VRYCFG command to vary off the commu- 
nications configurations when they are no longer 
needed. You can use the VRYCFG command either 
within the application CL or interactively. 
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Figure 3-15. Remote System Starts a Session with a Program Start Request 


Target Program 


Figure 3-15 shows the sequence of events that occurs when 
the remote system starts the session by sending a program 
start request. 
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You must vary on the communications configurations 
before programs can use them to communicate with a 
remote system. Use the VRYCFG command to vary 


on the configurations. 


Note: Before your system 


can process incoming 


program start requests, you must define subsystem 
communications entries using the ADDCMNE 
command. Refer to the Communications Management 


book for more information. 
A program on the AS/400 s 


ystem is started when your 


system receives the program start request from the 


remote system. 
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The program must open the ICF file. 


The program must acquire the requesting program 
device to establish a logical connection to the session 
and the transaction. The program device name speci- 
fied on the acquire operation must be associated with a 
remote location name of *REQUESTER 
(RMTLOCNAME(*REQUESTER), specified on either 
the ADDICFDEVE or the OVRICFDEVE command). 


Your program can send or receive data, depending on 
the procedures previously set up with the remote 
system. 


Either program can end the transaction when all data 
has been sent or received. 


Your program must close the ICF file. 


Use the VRYCFG command to vary off the commu- 
nications configurations when they are no longer 
needed. 


The previous outline summarizes the sequence of events example, you can acquire and release multiple program 


needed for both source and target programs. Overall, every devices in the same program. You can also run multiple pro- 
event is required, but different subsets of events can be grams without varying on and varying off the communications 
repeated without repeating the whole series of events. For configurations. 
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Chapter 4. Intersystem Communications Function Files 


This chapter describes the ICF files, including: 


e Using ICF file commands 
¢ Creating and changing ICF files 
e Identifying the program devices used with ICF files 


Chapter 5 describes how you use ICF files. 


Introduction to Intersystem 
Communications Function Files 


A device file is a description of how input data is presented 
to a program from a device and how output data is presented 
to a device from a program. A device can be a physical 
device or a remote system. For example: 


e For asynchronous communications, a device can be an 
ASCII terminal. 


e For advanced program-to-program communications 
(APPC), a device can be a logical unit on a remote 
system. 


Device files do not contain data. Device files contain the file 
description identifying the device to be used and the record 
formats used by the application programs. The record 
formats and associated processing keywords are defined in 
the data description specifications (DDS) source. 


The type of device file used for communications is the ICF 
file. The ICF file allows the definition of program devices for 
different communications types. The communications types 
are advanced program-to-program communications (APPC), 
Systems Network Architecture upline facility (SNUF), binary 
synchronous communications equivalence link (BSCEL), 
asynchronous, intrasystem, finance, and retail communica- 
tions. Your application program writes data to and reads 
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Figure 4-1. ICF File Overview 


© Copyright IBM Corp. 1997 


data from the file. You can specify whether the data is to be 
read from a specific program device or from the first program 
device that responds to a request. You always write data to 
a specific program device. 


Note: References to APPC apply to APPC over TCP/IP 
communications also. 


The ICF file allows multiple sessions with different remote 
systems. You can define and use up to 256 program 
devices with an ICF file. The program devices can be a 
combination of different communications types. You must 
create the necessary communications configuration 
descriptions for the program devices defined to the file. 


Multiple programs (in the same job or separate jobs) can use 
the same ICF file simultaneously. Each program can have 
256 program devices per file. 


The file description information for an ICF file is derived from 
the parameters on the Create Intersystem Communications 
Function File (CRTICFF) command or the Change Inter- 
system Communications Function File (CHGICFF) command. 
The record format information is derived from the DDS that 
define each record format in the device file and from the 
fields within each format. 


You must also use either the Add Intersystem Communica- 
tions Function Device Entry (ADDICFDEVE) or the Override 
Intersystem Communications Function Device Entry 
(OVRICFDEVE) command to specify the program devices 
used with the file. These commands provide the connection 
between the program device name and the remote location 
name. 


The ICF file has attributes unique to ICF and attributes 
common to other types of device files. Figure 4-1 provides 
an overview of ICF files. 


Communications 
Device 


Description 
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Notes: 
1. The ICF file is created by using the CRTICFF command. 


2. The RMTLOCNAME parameter on the ADDICFDEVE 
command associates a remote location name to a 
program device. The remote location name is used to 
select the appropriate device description. 


3. Not all communications types require an explicitly- 
created device description. For more information, see 
the appropriate communications programming book for 
the communications type you are using. 


If you use system-supplied formats (described in Chapter 7), 
ICF supplies a file for your use. This file is QICDMF in 
QSYS. If you use this file in your program, you do not need 
to define DDS or create a file. However, you do need to 
define the program device entry with the OVRICFDEVE 
command. 


DDS and system-supplied formats provide parallel functions 
for ICF. System-supplied formats provide a majority of the 
function without the need to code DDS or to create an ICF 
file. DDS provides the following additional functions: 


e Externally described data 


e Additional processing (for example, CONFIRM pro- 
cessing for APPC) 


e Indicators to determine session state information 


¢ More flexibility — DDS keywords can be used together 
in multiple combinations 


Intersystem Communications Function File 
Commands 


Three types of commands apply to ICF files: file-level attri- 
bute commands, program device entry commands, and com- 
mands for displaying information. 


File-Level Attribute Commands 


The file-level attribute commands are: 


Create Intersystem Communications Function File 
(CRTICFF) 
This command creates an ICF file that can be used with 
communications devices. After the command runs, the 
file contains the file attributes and the record format defi- 
nitions. 


Change Intersystem Communications Function File 
(CHGICFF) 
This command changes the file attributes of an ICF file. 


Override with Intersystem Communications Function File 
(OVRICFF) 
This command can (1) override (replace) the file named 
in the program, (2) override certain parameters of a file 
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used by the program, or (3) override the file named in 
the program and override certain parameters of the file 
to process. 


Delete Override (DLTOVR) 
This command deletes the effect of the OVRICFF 
command. 


Delete File (DLTF) 
This commands deletes the file from the system and 
frees the storage space allocated to that file. 


Program Device Entry Commands 


The program device entry commands are: 


Add Intersystem Communications Function Device Entry 
(ADDICFDEVE) 
This command adds a program device entry with the 
specified device name and attributes to the file. You can 
use this command multiple times to add multiple 
program device entries to the same file. 


Change Intersystem Communications Function Device 
Entry (CHGICFDEVE) 
This command changes the program device entry that 
was defined with the ADDICFDEVE command. 


Override Intersystem Communications Function Device 
Eniry (OVRICFDEVE) 
This command is used either (1) to override attributes 
specified in the ADDICFDEVE command or (2) to tem- 
porarily associate the specified program device name 
and attributes to the file. This command is different from 
the ADDICFDEVE command because it does not perma- 
nently change the ICF file. The association between the 
program device entry and the file is only for the job in 
which the command runs. You can use this command 
multiple times to override multiple program device 
entries to the file. 


Delete Override Device Entry (DLTOVRDEVE) 
This command deletes the effect of the OVRICFDEVE 
command. 


Remove Intersystem Communications Function Device 
Entry (RMVICFDEVE) 
This command removes one or more program device 
entries from the file. 


Display Information Commands 


The commands used to display information are: 


Display File Description (DSPFD) 
This command displays information about the attributes 
of a device file. 


Display File Field Description (DSPFFD) 
This command displays field-level information for a 
device file. 


Display Override (DSPOVR) 
This command displays file overrides at any active call 
level for a job. 


Creating an Intersystem Communications 
Function File 


Use the CRTICFF command to create an ICF file. The ICF 
file contains a file description made up of information speci- 
fied in two places: 


e The source file containing the DDS 
¢ The CRTICFF command 


Figure 4-2 shows ICF file creation. 
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Figure 4-2. Creating an ICF File 


Defining the Record Formats for an 
Intersystem Communications Function File 


DDS provides two functions. The first function is to describe 
the data format as used by the program, by defining record 
formats and the fields within the records. The second func- 
tion is to define the characteristics of the operation to be 
done on the record by the use of DDS keywords. DDS is 
supplied in the source file specified on the SRCFILE param- 
eter of the CRTICFF file command. 


Refer to the DDS Reference book for information on using 
DDS to define record formats and fields. Chapter 6 
describes the function of DDS keywords unique to commu- 
nications. Information on coding the DDS keywords is in the 
DDS Reference book. 


File Attributes 


Figure 4-3 identifies the attributes used with an ICF file. 
These attributes are specified by the parameters on the 
CRTICFF command. 


Figure 4-3. ICF File Attributes 


Parameter Description 

FILE Name of the file 

SRCFILE Name of the source file containing the DDS 

SRCMBR Name of the member within the source file 
containing the DDS 

OPTION Output listing options 

GENLVL Severity level of DDS messages that cause 
the file create to fail 

FLAG Minimum security level of error messages to 
be listed 

ACQPGMDEV Program device to acquire when the file is 
opened 

MAXPGMDEV Maximum number of program devices the 
program can acquire using this file (This 
parameter also restricts the number of device 
entries that can be added with the 
ADDICFDEVE command.) 

MAXRCDLEN Maximum record length used with the file 

WAITFILE Length of time to wait for file resources to 
become available 

WAITRCD Length of time to wait for a record to be 
returned when performing a read-from-invited- 
program-devices operation 

DTAQ Name and library of the data queue on which 
entries are placed 

SHARE Specifies whether the open data path for the 
file is shared with other opens of the same file 
in the routing step 

LVLCHK Record format level indicators check 

AUT Default authority granted to the public 

REPLACE Specifies whether an existing ICF file is 
replaced 

TEXT Descriptive text describing the file 


Acquiring a Program Device when the File 
Is Opened 


Use the acquire program device (ACQPGMDEV) parameter 
on the CRTICFF command to specify the program device 
you want to acquire when the file opens. The values for the 
ACQPGMDEV parameter are described below. 


*NONE: Specifies that no program devices are acquired 
when the file opens. This value is the default for the 
ACQPGMDEV parameter. 


When you specify “NONE, the program can open the file 
without consideration of whether the devices to be used 
are available. In addition, the program does not need a 
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routine to handle errors that occur if the program device 
cannot be acquired when the file is opened. 


The program must acquire at least one program device 
to the file before doing any input/output (I/O) operations. 


Program Device Name: Specifies the name of a 
program device to be acquired to the file when the file is 
opened. You can specify the name of any program 
device associated with the file using the ADDICFDEVE 
or OVRICFDEVE commands. See “Identifying the 
Devices Used with an Intersystem Communications 
Function File” on page 4-7 for more information on how 
to define a program device to an ICF file. The specified 
program device must be associated with the file before 
the file is opened. 


When you specify a program device name for the 
ACQPGMDEV parameter, space is reserved in the file 
for the specified program device. Refer to the next 
section for information about reserving space in the file 
for program devices. 


Determining the Maximum Number of Program 
Devices: The maximum program device (MAXPGMDEV) 
parameter on the CRTICFF command specifies the 
maximum number of program devices you want to use in the 
file. Use the ADDICFDEVE or the OVRICFDEVE command 
to associate program devices to the file. Following are 
guidelines for specifying the value for the MAXPGMDEV 
parameter: 


e An ICF file can either be a single- or a multiple-device 
file. If your program uses the file as a single-device file, 
specify a value of 1 on the MAXPGMDEV parameter. If 
your program uses the file as a multiple-device file, 
specify the number of program devices simultaneously 
active to the file. If your file is a single-device file, only 
one session can be active in the program and the use of 
the read-from-invited-program-devices operation is 
restricted. If your file is a multiple-device file, more than 
one session can be active simultaneously and the read- 
from-invited-program-devices operation is allowed. 
Refer to the appropriate language reference book to 
learn: 


— How to indicate that the program should use the file 
as a single- or multiple-device file 


— The differences between single- and multiple-device 
files 


e The value specified on the MAXPGMDEV parameter 
restricts the number of program device entries you can 
add to the file using the ADDICFDEVE command. 


e The value specified for the MAXPGMDEV parameter 
indicates the maximum number of program devices you 
want to have simultaneously active for this file. If you 
specify a program device name on the ACQPGMDEV 
parameter, space is reserved in the file for the program 
device to be acquired when the file opens, and this 
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device must be counted when determining the 
MAXPGMDEV value. You must, however, still define a 
program device entry to the file for this program device. 


For example, if you specify a program device name of 
PGMDEVA on the ACQPGMDEV parameter and a 1 on 
the MAXPGMDEV parameter, the only device that can 
be added to the file with the ADDICFDEVE command is 
PGMDEVA. PGMDEVA is also the only device that can 
be used with the file. If you specify a 2 for the 
MAXPGMDEV parameter, you can add and use 
PGMDEVA and one additional device with the file. 


e The value you specify on the MAXPGMDEV parameter 
should be no larger than necessary. If you specify a 
larger number of program devices than your program 
requires, the program uses unnecessary system 
resources. If the requirements for the maximum number 
of devices change, you can use the CHGICFF command 
to change the MAXPGMDEV parameter. Refer to 
“Changing an Intersystem Communications Function 
File” on page 4-5 for more information. 


e The number of devices a program can handle (while 
maintaining a reasonable response time) is determined 
by the amount of processing the program does for each 
program device. 


Determining the Maximum Record Length: Use the 
maximum record length (MAXRCDLEN) parameter on the 
CRTICFF command to specify the maximum record length 
you want to use with the file. This length is used in calcu- 
lating the size of allocated I/O buffers and this determines 
the largest I/O operation that can be performed against the 
file. The following are guidelines for specifying the value for 
the MAXRCDLEN parameter: 


e lf your program uses externally described data and you 
do not vary the defined length of record formats, use the 
default value of *CALC. The system then generates the 
maximum record length based on the largest record 
defined in the file. 


e If you use system-supplied formats in combination with 
an externally described file, this parameter defines the 
maximum length you can specify on the system-supplied 
formats. Since this parameter determines the allocation 
of I/O buffers and the system rejects output requests 
that are longer than the allocated I/O buffers, this param- 
eter is important if you try to use a system-supplied 
format to write a record larger than the largest record in 
the file. Refer to Chapter 7 for more information about 
system-supplied formats. 


e The value specified on the MAXRCDLEN parameter 
should be no larger than necessary. The value specified 
can be smaller than the largest record in the file. This 
can be used to minimize the size of I/O buffers allocated 
for a program that is using a common file that contains a 
larger record length than is used by the program. 


Determining the Wait-for-File Resources Value: 

Use the wait file (WAITFILE) parameter on the CRTICFF 
command to specify the maximum amount of time the open 
and acquire operations wait before a file resource (such as a 
device description) becomes available for use by the file. 
When a file resource is available to an ICF file, the resource 
is allocated to the job using that file, and is not available to 
other jobs. 


Some communications types also use the WAITFILE param- 
eter to determine the amount of time to wait for remote com- 
munications session resources to become available. 


The following are guidelines for specifying the value for the 
WAITFILE parameter: 


e If a session is not available for allocation to the job in 
which your program is running, the system waits until the 
session is available or until the specified amount of time 
elapses. 


e If you specify an extremely large value, your program 
waits a long time before it is notified that the session 
cannot be established. 


e The wait time needs to be increased if your program 
fails at open or acquire time while trying to acquire a 
program device to a session that appears to be avail- 
able. 


Determining the Wait-for-Record Value: Use the wait 
record (WAITRCD) parameter on the CRTICFF command to 
specify the maximum number of seconds that the read-from- 
invited-program-devices operation waits for a response from 
the invited program devices. Although the normal response 
is from an invited program device, the read-from-invited- 
program-devices operation may also complete with a job- 
being-canceled (controlled) indication. 


The value specified for the WAITRCD parameter has no 
effect on input operations directed to a specific program 
device. Instead, a read operation to a specific program 
device waits until a response is available from that program 
device. 


Refer to Chapter 5 for more information on the read-from- 
invited-program-devices and read operations. 


If your program does not use the read-from-invited-program- 
devices operation, you need not be concerned about the 
value specified on this parameter. 


The following are guidelines for selecting the WAITRCD 
parameter value if your program uses the read-from-invited- 
program-devices operation: 


*NOMAX: Indicates that the read-from-invited-program- 
devices operation should wait until a response is avail- 
able from an invited program device. This is the default. 


When *NOMAX< is specified on the WAITRCD param- 
eter, the read-from-invited-program-devices operation 


does not return control to the program unless a 
response is available from an invited program device or 
the job is ending in a controlled way. If the invited 
program devices are unable to return a response, the 
program waits until the job is ended. 


*IMMED: Indicates that the read-from-invited-program- 
devices operation should not wait for a response from an 
invited program device. 


Specifying *IMMED allows the program to receive a 
response (if available) from an invited program device. 

If no response is available, the program receives a 0310 
return code without waiting for a time limit to end. 


Number of Seconds: Specifies the number of seconds 
that the read-from-invited-program-devices operation 
waits for a response from an invited program device. If 
no response is received from the invited program 
devices within the specified amount of time, the program 
is informed through a major/minor return code. 


Specifying the number of seconds allows the program to 
receive a response from an invited program device if a 
response is available within the specified amount of 
time. If no response is available within the specified 
amount of time, the program receives a 0310 return 
code, indicating that the time limit has ended. 


Using a Data Queue: If you want your program to wait 
for an ICF file and a data queue at the same time, use the 
data queue (DTAQ) parameter on the CRTICFF command. 
The program can also wait for a display file if the same data 
queue is specified on the CRTDSPF, CHGDSPF, or 
OVRDSPF commands. Refer to “Waiting for a Display File, 
an ICF File, and a Data Queue” on page 5-15 for more infor- 
mation. 


Determining Other CRTICFF Command Parameter 
Values: Refer to the CRTICFF command in the CL Refer- 
ence book to determine the appropriate values for the 
SRCFILE, SRCMBR, OPTION, GENLVL, FLAG, LVLCHK, 
SHARE, AUT, REPLACE, and TEXT parameters. 


Changing an Intersystem Communications 
Function File 


Use the CHGICFF command to change the file-level attri- 
butes of an ICF file. The changes made to the file are 
system-wide and affect all programs that open the file after 
the CHGICFF has been done. Any programs that already 
have opened the file are not affected during the current run. 
Use the parameters in Figure 4-4 for changing file-level attri- 
butes values specified on the CRTICFF command. 


Figure 4-4 (Page 1 of 2). File Attributes for Changing an ICF File 
Parameter 
ACQPGMDEV 


Description 


Program device to be acquired when the file is 
opened 
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Figure 4-4 (Page 2 of 2). File Attributes for Changing an ICF File 


Parameter Description 


MAXPGMDEV Maximum number of program devices that can 
be acquired by the program using this file; this 
parameter also restricts the number of device 
entries that can be added with the 


ADDICFDEVE command. 


MAXRCDLEN Maximum record length used with the file 


WAITFILE Length of time to wait for file resources to 


become available 


WAITRCD Length of time to wait for a record to be 
returned when performing a read-from-invited- 


program-devices operation 


DTAQ Name and library of the data queue on which 


entries are placed 


SHARE Specifies whether the open data path for the file 


is shared with other opens of the same file in 
the routing step 


LVLCHK 
TEXT 


Record format level indicators check 
Descriptive text for describing the file 


Overriding an Intersystem 
Communications Function File 


Use the OVRICFF command to temporarily override the file 
named in the program, the file-level attributes of the file, or 
both. The OVRICFF command affects only the job in which 
it is run. Use the parameters in Figure 4-5 for overriding file- 
level attribute values specified on either the CRTICFF or 
CHGICFF command. 


Figure 4-5. File Attributes for Overriding an ICF File 


Parameter Description 

FILE Name of file to override (same file name as 
application) 

TOFILE Name of file 

ACQPGMDEV Program device to be acquired when the file is 
opened 

MAXRCDLEN Maximum record length used with the file 

WAITFILE Length of time to wait for file resources to 
become available 

WAITRCD Length of time to wait for a record to be 
returned when performing a read-from-invited- 
program-devices operation 

DTAQ Name and library of the data queue on which 
entries are placed 

SHARE Specifies whether the open data path for the file 
is shared with other opens of the same file in 
the routing step 

LVLCHK Record format level indicators check 

TEXT Descriptive text for describing the file 

SECURE Specifies whether this file is secure from previ- 


ously called override commands 
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Override commands can be scoped to the job level, the acti- 
vation group level (the default), or the call level. Overrides 
scoped to the job level remain in effect until they are deleted, 
replaced, or until the job in which they are specified ends. 
Overrides scoped to the activation group level remain in 
effect until they are deleted, replaced, or until the activation 
group is deleted. Overrides scoped to the call level remain 
in effect until they are deleted, replaced, or until the program 
in which they were issued ends. 


There are two common ways of using the override pro- 
cessing. One way is to scope all your override processing to 
the job level, as shown in the following example: 


MAINCLPGM 
OVRICFF FILE(ICFFILE) TOFILE(ICFFILE) WAITRCD(2) OVRSCOPE(*JOB) 
CALL CPGM 
CALL CBLPGM 
CALL RPGPGM 


In the example, the OVRICFF applies to all the other pro- 
grams, because overrides that are scoped to the job level 
affect all programs in the job. The WAITRCD value of 2 
seconds is in effect for the programs CPGM, CBLPGM, and 
RPGPGM. 


The second approach is to do your override processing at 
the highest possible call level, as shown in the following 
example: 


MAINCLPGM 
CALL CCLPGM 
CALL CBLCLPGM 
CALL RPGCLPGM 


CCLPGM 
OVRICFF FILE(ICFFILE) TOFILE(ICFFILE) WAITRCD(2) 
CALL CPGM 


CBLCLPGM 
OVRICFF FILE(ICFFILE) TOFILE(ICFFILE) WAITRCD(4) 
CALL CBLPGM 


RPGCLPGM 
OVRICFF FILE(ICFFILE) TOFILE(ICFFILE) WAITRCD(4) 
CALL RPGPGM 


When CPGM is called, the WAITRCD value in effect is 2 
seconds. The effects of the OVRICFF in CCLPGM are 
deleted when CCLPGM exits to the MAINCLPGM program. 
The WAITRCD specified on the CRTICFF is now in effect 
again. When CBLPGM or RPGPGM is called, the WAITRCD 
value in effect is 4 seconds. 


Refer to the Data Management book for the rules governing 
the use of override commands. 


Use the DLTOVR command to delete the effect of the 
OVRICFF command. 


You can use the DSPOVR command to display the file over- 
ride in effect. 


The WAITRCD parameter has no meaning in the 
FORTRAN/400 language, as the FORTRAN/400 language 
does not allow the read-from-invited-program-device opera- 
tion. 


Identifying the Devices Used with an 
Intersystem Communications Function File 


A program communicates through a program device in an 
ICF file. A program device entry has two functions: 


e Associates a program device name with a remote 
location name 


e Establishes a set of program communications-type- 
dependent attributes 


The program device name need not be the same as the 
name of the device description. To establish an association 
between the name used in the program (program device 
name) and the communications configurations, you must 
define a program device entry to the file. 


You must define one program device entry for each name 
used in the program (even if the name of the configuration is 
the same as the name used in the program). If the program 
is written to handle the requesting program device, you must 
define a program device entry for the requester by specifying 
a special value of “REQUESTER for the RATLOCNAME 
parameter on the ADDICFDEVE or the OVRICFDEVE 
command. 


You must define the program device entry before the 
program device can be acquired. If you specified a program 
device on the ACQPGMDEV parameter of the CRTICFF 
command, you must define the appropriate program device 
before the file can be opened. 


Note: The FORTRAN/400 language does not support 
program device names. To establish an ICF session using 
the FORTRAN/400 language, you must use the 
ACQPGMDEV parameter on the CRTICFF, CHGICFF, or 
OVRICFF commands. You can have only one ICF session 
for each ICF file opened using the FORTRAN/400 language. 


Defining Program Device Entries 
Permanently 


You can define a program device entry in numerous ways. 
For example, the ADDICFDEVE command permanently adds 
the program device entry to the file, while the OVRICFDEVE 
command provides the same function without changing the 
file. Figure 4-6 on page 4-8 shows how to define a program 
device entry to an ICF file. 


Note: Figure 4-6 on page 4-8 shows only one program 
device entry. Multiple program device entries can be 
defined. The maximum number of entries is determined by 
the MAXPGMDEV parameter specified at file creation. 


You can define a program device entry to an ICF file perma- 
nently or temporarily. A permanent definition is system-wide 
and affects all users of the file. A permanent definition adds 
the program device entry to the specified file. A temporary 
definition does not change an ICF file. The definition is only 
associated with the job in which the command is entered. 
Because temporary changes are not directed to a specific 


ICF file, all ICF files associated with the job or call level are 
affected. 


Use the ADDICFDEVE command to add a program device 
entry to an ICF file. The program device entry is added to 
the file specified in the FILE parameter. 


Use the CHGICFDEVE command to change a program 
device entry previously added to an ICF file with the 
ADDICFDEVE command. The PGMDEV parameter identi- 
fies the entry to change. You can use the CHGICFDEVE 
command to change the association to the communications 
configurations, the program communications-type-dependent 
attributes, or both. 


Use the RMVICFDEVE command to remove a program 
device entry previously added to an ICF file with the 
ADDICFDEVE command. The PGMDEV parameter identi- 
fies the entry to remove. 


Defining Program Device Entries 
Temporarily 


In addition to the file attrioutes and record formats similar to 
those in other device files, an ICF file also contains program 
device entries that provide the link between the application 
and each of the remote systems or devices with which your 
program communicates. 


The following lists the CL commands that provide override 
functions for device entries: 


DLTOVRDEVE 
Delete Override Device Entry: Deletes one or more 
program device overrides that were previously spec- 
ified in a call level. 


OVRICFDEVE 
Override with Intersystem Communications Program 
Function Device Entry: Used to temporarily add the 
program device entry and the remote location name 
to the ICF file or to override a program device entry 
with the specified remote location name and attri- 
butes for an ICF file. 


A program device entry has two functions: 


e lt associates a program device name with a remote 
location. 

e It establishes a set of program communications-type 
dependent attributes. 


Multiple program device entries can be defined. Each 
program device entry must have a unique program device 
name. The maximum number of entries is determined by the 
MAXPGMDEV parameter specified at file creation. 


Program device entries may be defined by the ADDICFDEVE 
command or the OVRICFDEVE command. The 
ADDICFDEVE command makes a permanent addition to the 
file, and the OVRICFDEVE command makes a temporary 
change to the program device information. It is not neces- 
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Figure 4-6. Defining a Program Device Entry to an ICF File 


sary to add a program device entry before overriding it. 
Several ADDICFDEVE commands may be used to add mul- 
tiple program devices to the same file. Several 
OVRICFDEVE commands may be used to change different 
device entries. 


Overriding Remote Location Name: The device entry 
override may be used to temporarily define or change the 
remote location name associated with the program device 
entry. 


The following example demonstrates the use of the 
OVRICFDEVE command to override the remote location 
name: 


OVRICFDEVE PGMDEV(PGMDEVA) RMTLOCNAME (CHICAGO) 
CALL RPGPGM 


In this example, when RPGPGM specifies PGMDEVA, 
remote location CHICAGO is used. 


Overriding Session Attributes: The device entry over- 
ride may also be used to temporarily change the character- 
istics of the communications session that is established when 
the program device is acquired. 


Although some of the session attributes have system-level 
defaults, the default for the majority of these attributes is 
information supplied during communications configuration. 


Session attributes are identified as parameters on the 
ADDICFDEVE or OVRICFDEVE command. Parameters not 
specified on either command take on the appropriate system 
default or specified configuration value. If the same param- 
eter is specified on both the ADDICFDEVE and 
OVRICFDEVE commands, the value specified on 
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OVRICFDEVE overrides the value declared on the 
ADDICFDEVE command. 


The following example demonstrates the use of the 
OVRICFDEVE command to override the format selection pro- 
cessing attribute: 


OVRICFDEVE PGMDEV(PGMDEVA) FMTSLT(*PGM) 


In this example, format selection is changed to *PGM. This 
overrides what was previously defined in the program device 
entry. Refer to the appropriate communications program- 
ming book for more information on the use of the session 
attributes. Refer to the CL Reference book for more informa- 
tion on the format and allowable values of the parameters on 
the OVRICFDEVE command. 


Overriding Remote Location Name and Session 
Attributes: This form of the override device entry is a 
combination of the previous two forms. With this form of 
override, you can override the remote location that is used by 
a program, and you can also override the session attributes. 


Applying OVRICFDEVE Command: Device entry 
overrides follow most of the same rules as file overrides. 
They are effective from the time they are specified until they 
are replaced or deleted or until the program in which they 
were specified ends. Any program device entry overrides 
that are in effect at the time the device is acquired are 
applied. 


The OVRICFDEVE command can be used to initialize an 
environment or change the environment while running. 


In the following example, the OVRICFDEVE commands are 
initializing an environment: 


Override 1 OVRICFDEVE PGMDEV(PGMDEV1) + 
RMTLOCNAME(BOSTON) . . . 

Override 2. OVRICFDEVE PGMDEV(PGMDEV2) + 
RMTLOCNAME(ROCHMN) . . . 


CALL PGM(A) 
CALL PGM(B) 


CALL PGM(X) 


When the program uses any ICF file and acquires the 
program device named PGMDEV1, then the remote location 
named BOSTON and attributes from override 1 are used 
when establishing the communication session. 


When the program uses an ICF file and acquires the 
program device named PGMDEV2, then the remote location 
named ROCHMN and attributes from override 2 are used 
when establishing the communication session. 


In the following example, the OVRICFDEVE commands are 
used to change the running environment: 


Override 1 OVRICFDEVE PGMDEVE(PGMDEV1) + 
RMTLOCNAME(BOSTON) . . . 
CALL PGM(A) 
Override 2 OVRICFDEVE PGMDEVE(PGMDEV2) + 


RMTLOCNAME(ROCHMN) . . . 
CALL PGM(A) 


The first time program A is called, an ICF file is opened and 
the program device named PGMDEV1 acquired. The remote 
location named BOSTON and attributes from override 1 are 
used when establishing the communication session. 


The second time program A is called, an ICF file is opened 
and the program device named PGMDEV2 is acquired. The 
remote location named ROCHMN and attributes from over- 
ride 2 are used when establishing the communication 
session. 


Applying OVRICFDEVE from Multiple Call Levels: When 
you have more than one override for the same program 
device at several call levels (nested calls), the order in which 
the overrides are applied to the program device is from the 
highest call level to the lowest call level. Any job level over- 
rides are applied last. 


To prevent overrides at lower call levels from being applied, 
see “Applying OVRICFDEVE with SECURE.” 


In the following example, override 2 is in the highest call 
level and override 1 is in the lowest call level. 


Override 1 OVRICFDEVE PGMDEV(PGMDEV1) + 
FMTSLT(*PGM) BATCH(«NO) 
CALL PGM(A) 
Program A 
Override 2 OVRICFDEVE PGMDEV(PGMDEV1) + 


FMTSLT(*RECID) APPID(PAYROLL) 
CALL PGM(X) 


When program X acquires program device PGMDEV1, the 
following attributes are used: 


FMTSLT(*PGM) 


BATCH(*NO) 
APPID(PAYROLL) 


From Override 1 
From Override 1 
From Override 2 


The attribute of FMTSLT(RECID) specified in override 2 is 
not used because it was overridden by FMTSLT(*PGM) 
specified in override 1. Override 1 overrides override 2. If 
there is a third override for program device PGMDEV1 
embedded in program X, it is overridden by override 2 and 
then override 1. 


A similar situation exists when you change the remote 
location to be used with the program device and you also 
change some of the attributes of the program device. For 
example: 


Override 1 OVRICFDEVE PGMDEV(PGMDEV1) + 
RMTLOCNAME (NYCAPPC) 
CALL PGM(A) 
Program A 
Override 2 OVRICFDEVE PGMDEV(PGMDEV1) + 


RMTLOCNAME(MPLSAPPC) + 
CNVTYPE(*USER) 
CALL PGM(X) 


When program X is ready to acquire PGMDEV1, it acquires 
remote location NYCAPPC instead of MPLSAPPC (because 
override 1 overrides override 2 remote location). Also, the 
conversation type is *USER (because of override 2). 


Applying OVRICFDEVE with SECURE: On occasion, 
you may want to protect program devices used by a program 
from overrides at lower call levels. 


You can prevent additional program device overrides by 
coding the SECURE(*YES) parameter on a program device 
override command for each program device needing pro- 
tection. This protects you from overrides at lower call levels. 


The following shows an example of a protected program 
device: 
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Override 1 OVRICFDEVE PGMDEV(PGMDEV1) + 
RMTLOCNAME (BOSTON) 
OVRICFDEVE PGMDEV(PGMDEV4) + 
RMTLOCNAME (ROCHMN) 
CALL PGM(A) 
Program A 
OVRICFDEVE PGMDEV(PGMDEV5) + 
RMTLOCNAME (NYC) 
CALL PGM(B) 
Program B 
OVRICFDEVE PGMDEV(PGMDEV1) + 
RMTLOCNAME (MPLS) SECURE (*YES) 
CALL PGM(X) 


Override 2 


Override 3 


Override 4 


When program X acquires program device PGMDEV1 for an 
ICF file, the remote location MPLS and attributes from over- 
ride 4 are used. Because override 4 specifies 
SECURE(*YES), override 1 is not applied. 


Deleting Device Entry Overrides: When a program 
returns from a call level containing program device entry 
overrides, the overrides are deleted, just as any file overrides 
are deleted. When control is transferred to another program 
(TFRCTL command) so that the program is running at the 
same call level, the overrides are not deleted. If you want to 
delete an override before the run is completed, you can use 


the Delete Override Device Entry (DLTOVRDEVE) command. 


This command only deletes overrides in the call level in 
which the command is entered. A DLTOVRDEVE command 
does not delete the effects of an ADDICFDEVE command. 
To remove an ADDICFDEVE command, you must use the 
Remove Intersystem Communications Function Program 
Device Entry (RMVICFDEVE) command. To identify an 
override, use the program device name specified on the 
PGMDEV parameter of the override. You can delete all 
overrides at this call level by specifying value *ALL for the 
PGMDEV parameter. For example: 


Override 1 OVRICFDEVE PGMDEV(PGMDEV1) + 
RMTLOCNAME (BOSTON) 

Override 2 OVRICFDEVE PGMDEV(PGMDEV4) + 
RMTLOCNAME (ROCHMN) 

Override 3 OVRICFDEVE PGMDEV(PGMDEV5) + 
RMTLOCNAME (NYC) 


Delete Override 1 
Delete Override 2 


DLTOVRDEVE PGMDEV (PGMDEV1) 
DLTOVRDEVE PGMDEV(*ALL) 


Delete override 1 causes override 1 to be deleted. Delete 
override 2 causes the remaining overrides (overrides 2 and 
3) to be deleted. 


Displaying Device Entry Overrides: Device entry 
overrides are not displayed by the Display Override 
(DSPOVR) command. There is no corresponding command 
to display device entry overrides. 


Mapping Program Device Name to 
Communications Configurations 


The first purpose of the program device entry is to associate 
a program device name with a device description. This 
mapping uses the parameters shown in Figure 4-7 on the 
ADDICFDEVE, CHGICFDEVE, and OVRICFDEVE com- 
mands. 


Note: References to APPC apply to APPC over TCP/IP 
communications also. 


PGMDEV 
Specifies the program device name being defined (the 
name used by the program to do operations). The 
program device name must be unique throughout all 
entries in the file. You can map two or more different 
program device names to the same communications 
configurations. This mapping allows you to have mul- 
tiple sessions through the same configurations, and to 
have different device attributes for the same configura- 
tions. PGMDEV is a required parameter. 


Figure 4-7. Mapping Parameters for All Communications Types 


Intra- 
Parameter Description APPC SNUF BSCEL Async system Finance Retail 
PGMDEV Program X X X X X x X 
device name 
RMTLOCNAME Remote X X Xx X X X X 
location name 
DEV Communica- x x x 
tions device 
description 
LCLLOCNAME Local location Xx 
name 
MODE Mode Xx 
RMTNETID Remote 
network ID 
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The other parameters are associated with information sup- 
plied at various times during configuration. The following 
descriptions show the relationship of these parameters to the 
program device definition. 


RMTLOCNAME 
Specifies the name of the remote location associated 
with the program device. The remote location name is 
the primary mapping to communications configurations. 
A remote location is associated with any device 
description that contains the same remote location name 
(RMTLOCNAME parameter on the Create Device XXXX 
(CRTDEVXXXX) command). For APPC, intrasystem, 
and SNUF communications, there can be a one-to-many 
relationship between the remote location name and the 
device description. For asynchronous, BSCEL, finance, 
and retail communications, there is a one-to-one 
relationship. 


The remote location name is used by the system to 
select the device description. For those communications 
types that support multiple device descriptions per 
remote location, each communications type defines the 
criteria for selecting the best device. For a given remote 
location name, a list of devices (one or more) may be 
available for use. 


Each communications type has specific rules for defining 
what constitutes an available device. Because asyn- 
chronous, BSCEL, finance, and retail communications 
have a one-to-one relationship between the device and 
remote location name, no device selection process is 
necessary. APPC, intrasystem, and SNUF communica- 
tions all have a means for selecting the best available 
device for use. 


For APPC, intrasystem, and SNUF communications, if 
you want to use a specific device description instead of 
allowing the system to select it for you, use the DEV 
parameter to further qualify the remote location to a spe- 
cific device description. 


Figure 4-8 on page 4-12 shows the relationship of the 
remote location to the device description. Your program 
selects the communications type and communications 
link by acquiring a program device associated with a 
remote location name. The system selects a device 
description, based on availability (such as varied on and 
not in use), and other parameters that were specified 
when the program device entry was defined (such as 
device description). Note that multiple device 
descriptions can contain the same remote location 
name. In Figure 4-8 on page 4-12, if your program 
acquires a program device associated with a remote 
location of 'A', the system either selects DEVD1 or 
DEVD2, and the session established uses the APPC 
communications type. 


For additional information on how the system processes 
the RMTLOCNAME, DEV, LCLLOCNAME, and 
RMTNETID parameters for APPC, refer to the APPC 
Programming book. 


The remote location need not exist at the time you 
define the program device entry. However, the remote 
location must exist (either as a device description on the 
system, or as a remote location in the network) when the 
program device is acquired. 


If the communications type you are using allows multiple 
sessions per remote location, the same remote location 
can be mapped to different program device names. 


If the program device entry is being defined to process 
incoming program start requests, the special value of 
“REQUESTER must be used for the RATLOCNAME 
parameter. The remaining parameters on the 
ADDICFDEVE, OVRICFDEVE, and CHGICFDEVE com- 
mands in Figure 4-7 on page 4-10 do not apply (except 
PGMDEV) and should not be specified. 


RMTLOCNAME is a required parameter. 


DEV 


Further qualifies the remote location to a specific com- 
munications device description. 


DEV is an optional parameter. If you do not specify the 
DEV parameter, and there are several communications 
device descriptions associated with the remote location, 
the system determines which device to use. Note that 
the device used may not be the one you want (for 
example, the device you want may not be varied on). 


Note: If you rename a device after specifying the 
device name and remote location, you must update your 
ICF file accordingly. 


LCLLOCNAME 


Specifies the local location name of the local system. 
LCLLOCNAME is an optional parameter. 


MODE 


Specifies the mode used for the remote location. When 
you specify the special value *NETATR (the default) the 
mode in the network attributes is used. BLANK indi- 
cates that a mode name consisting of all blanks is used. 
MODE is an optional parameter. 


RMTNETID 


Specifies the remote network identifier of the remote 
location. When you specify the special value “NETATR 
(the default) the network identifier in the network attri- 
butes is used. *NONE indicates that a network identifier 
consisting of all blanks is used. RMTNETID is an 
optional parameter. 
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Device Descriptions 


DEVD1 
> 
Remote Location NameA RMTLOCNAME (A) APPC 
DEVD2 
Remote Location Name B >| RMTLOCNAME (A) APPC 
DEVD3 
Remote Location Name C aE | a RMTLOCNAME (B) ASYNCHRONOUS 
DEVD4 
Remote Location Name D > RMTLOCNAME (C) SNUFF 
DEVDS5S 
Remote Location Name E —_— id RMTLOCNAME (D) BSCEL 
DEVD6 
Remote Location Name F > RMTLOCNAME (EB) INTRASYSTEM 
DEVD7 
Remote Location Name G > RMTLOCNAME (F) FINANCE 
DEVD8 
>| RMTLOCNAME (G) RETAIL 
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Figure 4-8. Relationship of Remote Location Name to Device Description 


If any of the information supplied in the RMTLOCNAME, Communications-Type-Dependent 
DEV, LCLLOCNAME, MODE, or RMTNETID parameters Attributes 


conflicts, the acquire operation to the program device fails. 
ae . aay The second purpose of a program device entry is to establish 
For more specific information, refer to Communications Con- the characteristics of the communications session. These 
figuration book and the appropriate communications pro- communications-type-dependent attributes are specified as 
gramming book for the communications type you are using. parameters on the ADDICFDEVE, CHGICFDEVE, and 
OVRICFDEVE commands. 


Figure 4-9 describes the communications-dependent attri- 
butes used with an ICF file and the communication types that 
support each attribute. 


Note: References to APPC apply to APPC over TCP/IP 
communications also. 


Figure 4-9 (Page 1 of 3). Communications-Type-Dependent Attributes 


Intra- 
Parameter Description APPC SNUF BSCEL Async system Finance Retail 
FMTSLT Record format x xX X Xx X xX x 


selection technique. 
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Figure 4-9 (Page 2 of 3). Communications-Type-Dependent Attributes 


Parameter 


Description APPC SNUF 


Intra- 
BSCEL Async system Finance 


Retail 


CMNTYPE 


Identifies the commu- x Xx 
nications type you are 

using to select 

prompting on the 

command. 


X X X X 


X 


APPID 


VTAM* identifier of the Xx 
Customer Information 

Control (CICS/VS) or 

the Information Man- 

agement System for 

Virtual Storage 

(IMS/VS) host system. 


BATCH 


Specifies whether this X 
session is used for 

batch activity with 

IMS/VS host system. 


HOST 


Identifies type of host Xx 
system with which to 
communicate. 


ENDSSNHOST 


Specifies the command X 
used to end a session 
with the host system. 


SPCHOSTAPP 


Specifies whether the X 
support should be cus- 

tomized for special 

host applications 

outside the CICS/VS or 

IMS/VS application 

layer. 


INZSELF 


Specifies whether a X 
formatted INIT-SELF is 

used in place of the 

unformatted logon 

normally sent to the 

host system. 


HDRPROC 


Specifies whether X 
received function man- 

agement headers 

should be passed to 

the application. 


MSGPTC 


Specifies whether X 
message protection 
should be used. 


EMLDEV 


Specifies whether the Xx 
application is using 
3270 data streams. 


CNVTYPE 


Conversation type. xX 


BLOCK 


Specifies whether 
system or user will 
block and unblock 
transmitted records. 


RCDLEN 


Maximum record length Xx 
to transmit and receive. 


BLKLEN 


Maximum block length X 
to transmit and receive. 
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Figure 4-9 (Page 3 of 3). Communications-Type-Dependent Attributes 


Parameter Description APPC 


SNUF 


Intra- 


BSCEL Async system Finance Retail 


TRNSPY Specifies whether text 
transparency is used 
when sending blocked 


records. 


Xx 


DTACPR Specifies whether 
blanks are compressed 
when sending and 


receiving data. 


TRUNC Specifies whether 
trailing blanks are 
removed when sending 


data. 


OVRFLWDTA Specifies whether over- xX 
flow data (data in 

excess of what can be 

contained in the input 

buffer) is discarded or 


retained. 


GRPSEP Specifies separator for 
groups of data (data 


sets and documents). 


RMTBSCEL Specifies whether the 
session supports 
BSCEL commands and 


online messages. 


INLCNN Specifies the method of 
making a connection 
on the line when a 


session is established. 


SECURE Specifies whether this xX X 
program device is 

secured from previ- 

ously called override 


commands. 


You can specify any parameter on any communications type, 
but the parameter is ignored if it is not supported by the 
specified communications type. 


Although some attributes, like FMTSLT and CNVTYPE, have 
system-level defaults, the default for the majority of the 
parameters is the information supplied during communica- 
tions configuration. 


Parameters not specified on an ADDICFDEVE, 
CHGICFDEVE, or OVRICFDEVE command take on the 
appropriate system default or specified configuration value. 
If the same parameter is specified on both an ADDICFDEVE 
and OVRICFDEVE command, the value specified on the 
OVRICFDEVE overrides the value declared on the 
ADDICFDEVE command. 


The OVRICFDEVE command follows the general rules for 
override processing. For information on determining the 
result when two OVRICFDEVE commands are specified for 
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the same program device entry, refer to “Applying 
OVRICFDEVE from Multiple Call Levels” on page 4-9. 


Format Selection (FMTSLT): The FMTSLT parameter 
specifies the type of record selection used for input oper- 
ations for the program device specified in the PGMDEV 
parameter. 


Following are the values for the FMTSLT parameter: 


*PGM 
The record format is determined by the program. 


*RECID 
The record format is based on the use of the RECID 
DDS keyword. 


*RMTFMT 
The remote program determines the record format 
to use. 


These different values have meaning only when used in con- 
junction with specific DDS keywords. Refer to Chapter 5 for 
more information on format selection processing. 


Communications Type (CMNTYPE): The CMNTYPE 
parameter identifies the communications type for which you 
are defining a program device entry. This identification 
prompts you for the communications-type-dependent attri- 
butes associated with the communications type you are 
using. 


These values are available for the CMNTYPE parameter 
when *REQUESTER is not specified for the remote location 
name: 


*ALL 
Prompt for all possible communications-type- 
dependent attributes 


*APPC 
Prompt for all APPC-supported and APPC over 
TCP/IP supported attributes 


*SNUF 
Prompt for all SNUF-supported attributes 


*BSCEL 
Prompt for all BSCEL-supported attributes 


*ASYNC 
Prompt for all asynchronous communications- 
supported attributes 


*INTRA 
Prompt for all intrasystem communications- 
supported attributes 


*FINANCE 
Prompt for all finance communications-supported 
attributes 


*RETAIL 
Prompt for all retail communications-supported attri- 
butes 


This parameter is valid only if you enter the command inter- 
actively. 


However, when you specify *REQUESTER for the remote 
location name (RMTLOCNAME), you are only prompted for 
selected values based on the CMNTYPE parameter: 


*ALL 
Prompt for FMTSLT, CNVTYPE, RCDLEN, 
BLKLEN, and SECURE parameters 


*APPC 
Prompt for FMTSLT, CNVTYPE, and SECURE 
parameters 


*ASYNC 
Prompt for the FMTSLT and SECURE parameters 
*SNUF 
Prompt for FMTSLT, RCDLEN, BLKLEN, and 
SECURE parameters 
*BSCEL 
Prompt for the FMTSLT and SECURE parameters 


*INTRA 
Prompt for the FMTSLT and SECURE parameters 


*FINANCE 
Prompt for the FMTSLT and SECURE parameters 


*RETAIL 
Prompt for the FMTSLT and SECURE parameters 


Note: You can still specify values for the parameters that 
you are not prompted for (when *REQUESTER is specified 
for the remote location name) by typing those values and 
parameters on any command line with any of the program 
device entry commands. However, the parameter values you 
specify are ignored and no error return codes are issued. 


Secure from Override (SECURE): The SECURE 
parameter is valid only on the OVRICFDEVE command. 

This parameter does not apply to the ADDICFDEVE or 
CHGICFDEVE commands. This parameter is used to restrict 
the effects of override processing. 


Refer to the Data Management book for information about 
how the SECURE parameter works. Refer to the CL Refer- 
ence book for more information about the format and allow- 
able values. 


Other Communications-Type-Dependent Parame- 
ters: Each of these parameters has specific meaning and 
function, depending on the communications type you are 
using. Also, some of these parameters are ignored if the 
program device being defined is for a 
RMTLOCNAME(*REQUESTER). Refer to the appropriate 
communications programming book for more information on 
the use of these parameters. 


Refer to the CL Reference book for more information on the 
format and allowable values for these parameters. 


Intersystem Communications Function 
Command Summary 


Figure 4-10 on page 4-16 shows the relationship between 
ICF commands. 


The CRTICFF and CHGICFF commands are used to 
create the ICF file and work with file-level attributes. 
(The DLTF command is used to delete the ICF file.) 


fsThe ADDICFDEVE, CHGICFDEVE, and RMVICFDEVE 
commands allow defining program device- or 
communications-type-dependent information in the ICF 
file. The ADDICFDEVE command is optional, and is 
used only to support early binding, and setting of 
system-wide defaults. 


The OVRICFF command allows the changing of file- 
level attributes at the job level only. This command 
does not cause any permanent change, and it is not 
system-wide. (The DSPOVR command displays the 
information entered on the OVRICFF command. The 
DLTOVR command is used to delete the effects of the 
OVRICFF command.) 
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The OVRICFDEVE command affects the processing of 
the ICF file at the job level only. You do not specify 
the file on the override. Whatever ICF file is active at 
the time is the file that is overridden. It does not cause 
any permanent change, and it is not system wide. The 
OVRICFDEVE command uses a late binding function 
that ties the program device and the remote location at 


Creation Time Frame 
(permanent change) 


ICF File 
CRTICFF oe 
CHGICFF 
File 
Attributes 
Pele oe 
Device 
ADDICFDEVE Attributes 
CHGICFDEVE [~~~ ms 
RMVICFDEVE Se 


Figure 


4-16 


4-10. Relationship between ICF Commands 
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job time. The OVRICFDEVE command is also used to 
temporarily change communications-type-dependent 
attributes. The OVRICFDEVE command is job-wide, 
and has the characteristics of an override command. 
(The DLTOVRDEVE command is used to delete the 
effects of the OVRICFDEVE command.) 


Processing Time Frame 


(job-level change) 


OVRICFF 


OVRICFDEVE 
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Chapter 5. Using an Intersystem Communications Function File 


This chapter describes how an application uses an ICF file. 


To use an ICF file, identify it as a WORKSTN file in the ILE 
RPG programming language or as a TRANSACTION file in 
the ILE COBOL programming language. For the ILE C pro- 
gramming language, the type of file need not be specified. 


The ILE C, ILE COBOL, and ILE RPG programming lan- 
guages support an interface that allows the application to 
perform the following operations: 


¢ Open the file 

e Acquire a program device 

e Read from a program device 
e Write to a program device 

e Release a program device 

¢ Close the file 


The FORTRAN/400 language supports an interface that 
allows the application to perform the following operations: 


¢ Open the file 
e Read from the file (program device is implied) 
e Write to the file (program device is implied) 


¢ Close the file 


Read and write operations are done using a record that con- 
tains data description specifications (DDS) keywords. These 
DDS keywords allow more specific communications functions 
to be done with the read and write operations. ICF also sup- 
ports system-supplied record formats that can be used in 
place of user-defined DDS record formats. Refer to 

Chapter 6 and Chapter 7 for more information about the 
communications functions that can be performed with the 
read and write operations. 


Sample programs in Chapter 9 through Chapter 11 provide 
an overview of the language interface that supports these 
functions. For more information on the language interface, 
refer to the appropriate language reference book. 


Opening an Intersystem Communications 
Function File 


The processing done by the open operation depends on 
whether the open is a subsequent open of a shared file. The 
open is a subsequent open of a shared file if you specify 
SHARE(*YES) and the file is currently open with 
SHARE(*YES) specified. 


If the open is not a subsequent open of a shared file in the 


same job, the open operation allocates the file and any other 
resources needed to support the acquiring of program 
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devices to the file, and allocates the input/output (I/O) 
buffers. 


If the open is a subsequent open of a shared file, the 
program is simply attached to the already open file. Any 
program devices acquired by other programs are available 
for use by this program. The state or attributes of the file do 
not change during a subsequent open. For example, if the 
program device specified as the ACQPGMDEV parameter 
has been released, the subsequent open does not cause it to 
be acquired. 


After the file and other resources have been allocated, the 
open operation implicitly acquires the program device speci- 
fied by the ACQPGMDEV parameter, on the Create Inter- 
system Communications Function File (CRTICFF), Change 
Intersystem Communications Function File (CHGICFF), or 
Override Intersystem Communications Function File 
(OVRICFF) command. See “Acquiring a Program Device 
when the File Is Opened” on page 4-3 for information on 
how to specify the ACQPGMDEV parameter. 


The following is a description of the processing done by the 
open operation based on the ACQPGMDEV parameter value 
specified for the file: 


e If you did not specify the ACQPGMDEV parameter, or if 
you specified “NONE, the open operation does not 
acquire any program devices. A program device must 
be explicitly acquired for the file before the program tries 
any I/O operations to the file, or before another program 
opens the same file if the file is opened with 
SHARE(*YES) specified. 


e If you specify a program device name on the 
ACQPGMDEV parameter, the open operation acquires 
the specified program device. See “Acquiring a Program 
Device” on page 5-2 for information about acquiring a 
specific program device. 


If the open operation is not successful, the only allowable 
operation is closing the file. See “Closing an Intersystem 
Communications Function File” on page 5-17 for more infor- 
mation. 


Obtaining Information about the Open 
Intersystem Communications Function File 


After the program opens the file, an open feedback area is 
available to the program. This area contains information 
about the open file such as the file name, library name, and 
program device information. You can use the information in 
this area as long as the file is open. See Appendix C fora 
summary chart of the open feedback fields. Refer to the 
appropriate language reference book for information on 
accessing the fields. 


Acquiring a Program Device 


Before any input or output operations can be directed to a 
program device, the program device must be acquired. 


Only program devices defined to the file by use of the Add 
Intersystem Communications Function Device Entry 
(ADDICFDEVE) or the Override Intersystem Communications 
Function Device Entry (OVRICFDEVE) command can be 
acquired. See “Identifying the Devices Used with an Inter- 
system Communications Function File” on page 4-7 for more 
information about defining program device entries. 


A program device can be acquired in two ways: 


¢ One program device can be implicitly acquired through 
the open operation. Refer to “Opening an Intersystem 


Example 1 


Communications Function File” on page 5-1 for more 
information on an implicit acquire through the open oper- 
ation. 


e A program device can be explicitly acquired through the 
acquire operation. The acquire operation can be used 
many times with different program device names. 


When a program device is explicitly acquired with an acquire 
operation, you identify the session to establish by using the 
same program device name on the acquire as specified on 
the PGMDEV parameter on the ADDICFDEVE or the 
OVRICFDEVE command. 


The examples in Figure 5-1 show the relationship between 
the program device entry (defined using an ADDICFDEVE or 
an OVRICFDEVE command) and an ILE C, COBOL/400, 
and RPG/400 operation. 


ADDICFDEVE FILE(ICFFILE) PGMDEV(PGMDEVA) RMTLOCNAME (CHICAGO) 


RPG/400 Program 


'"PGMDEVA' ACQ ICFFILE 


Example 2 
OVRICFDEVE PGMDEV(PGMDEVA) 
COBOL/400 Program 
ACQUIRE 
Example 3 


OVRICFDEVE PGMDEV (PGMDEVA) 


C/400 Program 


RMTLOCNAME (CHICAGO) 


'PGMDEVA' FOR ICFFILE. 


RMTLOCNAME (CHICAGO) 


oe 


—Racquire (FP,"PGMDEVA") ; 


Figure 5-1. Relationship of Program Device Entries to Operations 


Note: For FORTRAN/400 programs, the acquire operation 
can be done implicitly by the system only when the ICF file is 
opened by specifying a program device name on the 
ACQPGMDEV parameter of the CRTICFF, CHGICFF, or 
OVRICFF command. The FORTRAN/400 language does not 
support program device names for ICF files; the program 
device is implied on read and write operations. 


Acquiring the program device automatically allows any I/O 
operations valid for that program device to be issued. For 
example, if the file is opened for input only, the read opera- 
tion is allowed, but the write operation is not allowed. 


The amount of time the system waits for resources to 
become available to complete the acquire request is speci- 
fied on the WAITFILE parameter of the CRTICFF, CHGICFF, 
or OVRICFF command. 
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The following sections describe some of the functions per- 
formed when a program device is acquired. 


Acquiring a Program Device — Source 
Program 


The system tries to allocate a new session with the remote 
location for the job in which the program is running. 
Some causes of a failed acquire operation are: 


e The device associated with the program device is not 
varied on. 


e The device description for the device associated with the 
program device is allocated to another job. 


e A session is not available for the remote location. 


Acquiring a Program Device — Target Program Device Definition List 


Program sand 

After a program device is acquired, the program device 
The system tries to establish a connection with the becomes part of the program device definition list. The 
requesting program device. An acquire operation to the program device definition list contains information about the 
requesting program device does not allocate a new session. program device, such as the program device class, device 
It only establishes a logical connection to the session and type, and invite state. 


transaction on which the target program was started. 


You can use the information in the program device definition 


The acquire operation fails if any of the following occur: list as long as the program device is acquired. The support 


e The session was previously ended by the target 


provided by the high-level language you use determines 
whether you can access this information. 


program. 
e A program not started by an evoke function issues an See Appendix C for a summary chart of the program device 
acquire for a requesting program device. definition list. Refer to the appropriate language reference 


book for information on accessing these fields. 


e The requesting program device is acquired for another 


file in the job. 


Get-Attributes Operation 


Obtaining Information about a Particular The get-attributes operation can be used at any time after a 


Program Device 


You can obtain information about a program device in two 


file has been opened to determine the status of a particular 
program device. The program device does not need to be 
acquired. The operation gets the current status about the 

session in which your program is communicating based on 


i the last ICF operation performed. The value for position 41 
¢ Using the program device definition list is an exception; this value is updated asynchronously by the 
e Using the get-attributes operation system. If the program device is not acquired, the informa- 


tion is obtained from the program device entry defined with 
the ADDICFDEVE or OVRICFDEVE command. 


The status information received by the get-attrioutes opera- 
tion contains the fields shown in Figure 5-2. 


Figure 5-2 (Page 1 of 3). Attribute Information Fields 


Position Value Meaning 

1 through 10 Name Program device name: The name the program used to identify the program device in the file to read 
and write from. 

11 through 20 Name Device description name: The device description associated with the program device name (specified 
during configuration and optionally on the ADDICFDEVE or OVRICFDEVE command). 

21 through 30 Name User ID: If the program was started locally, this is the user ID used to sign on to the work station. If 
the program was started as a result of a program start request, this is the user ID used to start the 
target program. 

31 | The device is an ICF device type. 

D The device is a display device. 
U Unknown. 
32 through 37 APPG APPC or APPC over TCP/IP communications type. 
SNUF SNUF communications type. 
BSCEL BSCEL communications type. 
ASYNC Asynchronous communications type. 
INTRA Intrasystem communications type. 
FINANC Finance communications type. 
RETAIL Retail communications type. 

38 Y This is a requesting program device. 

N This is a program device acquired by a source program. 

39 Y Program device has been acquired. 

N Program device has not been acquired. 
40 Y Input is invited for this program device. 
N Input is not invited for this program device. 
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Position Value Meaning 
41 Y: Invited input is available for this program device. 
N Invited input is not available for this program device. 
42 through 50 Reserved Not applicable to communications. 
51 Y Session has an active transaction. 
N Session does not have an active transaction. 
521 0 Synchronization level is NONE. 
1 Synchronization level is CONFIRM. 
2 Synchronization level is COMMIT. 
531 M Mapped conversation. 
B Basic conversation. 
54 through 61 Name Remote location name: This is the remote location associated with the program device name (speci- 
fied during configuration and on the ADDICFDEVE or OVRICFDEVE command). 
62 through 691 Name Local logical unit (LU) name. 
70 through 771 Name Local network ID. 
78 through 851 Name Remote LU name. 
86 through 931 Name Remote network ID. 
94 through 1011 Name Mode: This is the mode associated with the program device name (specified during configuration and 
optionally on the ADDICFDEVE or OVRICFDEVE command). 
102 through 1041 Reserved Not applicable to communications. 
1051 APPC conversation state. 
X'00' Reset. No conversation exists. 
X'01' Send. Program can send data. 
X'02' Defer receive. Program enters receive state after a confirm, flush, or commit operation completes 
successfully. 
X'03! Defer deallocate. Program enters deallocate state after a commit operation completes successfully. 
X'04' Receive. Program can receive data. 
X'05' Confirm. Program received a confirmation request. 
X'06' Confirm send. Program received a confirmation request and send control. 
X'07' Confirm deallocate. Program received a confirmation request and deallocate notification. 
X'08' Commit. Program received a commit request. 
X'09' Commit send. Program received a commit request and send control. 
X'0A' Commit deallocate. Program received a commit request and deallocate notification. 
X'0OB' Deallocate. Program received a deallocate notification. 
X'0C' Rollback required. Program must roll back changes to protected resources. 
106 through 1131 Name LU 6.2 conversation correlator 
114 through 1441 Reserved 
145 through 1461 Binary ISDN remote number length in bytes, including type and plan. 
147 through 1481 00 ISDN unknown remote number type. 
01 ISDN international remote number type. 
02 ISDN national remote number type. 
03 ISDN network specific remote number type. 
04 ISDN subscriber remote number type. 
06 ISDN abbreviated remote number type. 
149 through 1501 00 ISDN unknown remote number plan. 
01 ISDN/telephony remote number plan. 
03 ISDN data remote number plan. 
04 ISDN telex remote number plan. 
08 ISDN national standard remote number plan. 
09 ISDN private remote number plan. 
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Position Value Meaning 
151 through 1541 Reserved 
155 through 1901 Character ISDN remote number (blank-padded EBCDIC). 
191 through 194 Reserved 
195 through 1961 Binary ISDN remote subaddress length in bytes, including type. 
197 through 1981 00 ISDN NSAP remote subaddress type. 
02 ISDN user defined remote subaddress type. 
199 through 2381 Character ISDN remote subaddress (EBCDIC representation of hexadecimal data padded on the right with 
zeros) 
2391 Reserved 
240 0 Incoming ISDN call. 
1 Outgoing ISDN call. 
2 Not a switched ISDN connection. 
241 through 2421 Binary X.25 remote network address length in bytes. 
243 through 2741 Character X.25 remote network address (blank-padded EBCDIC). 
275 through 2781 Reserved 
279 through 2801 Binary X.25 remote address extension length in bytes, including type and extension. 
2811 0 X.25 address assigned according to ISO 8348/AD2. 
2 Not X.25 ISO 8348/AD2 address type. 
282 through 3211 Character X.25 remote address extension (EBCDIC representation of hexadecimal data) 
322 through 3251 Reserved 
326 0 Incoming X.25 switched virtual circuit (SVC). 
1 Outgoing X.25 SVC. 
2 Not X.25 SVC. 
327 through 3901 Character Name of program specified to be started as a result of the received program start request, even if a 
routing list caused a different program to be started. 
391 Binary Length of the protected logical unit of work identifier (LUWID). Must be from 0 to 26. 
392 Binary Length of the qualified LU name. Must be from 0 to 17. 
393 through 409 Character Network-qualified protected LU name in the following form: netid.luname. netid is the network identi- 
fier. /uname is the logical unit name. This field may be blank. 
410 through 415 Character Protected LUWID instance number. 
416 through 417 Binary Protected LUWID sequence number. 
Note: The protected LUWID identifies the current logical unit of work for a protected conversation. 
418 Binary Length of the unprotected LUWID. Must be from 0 to 26. 
419 Binary Length of the qualified LU name. Must be from 0 to 17. 
420 through 436 Character Network-qualified unprotected LU name in the following form: netid.luname. netid is the network 
identifier. /uname is the logical unit name. This field may be blank. 
437 through 442 Character Unprotected LUWID instance number. 
443 through 444 Binary Unprotected LUWID sequence number. 


Note: The unprotected LUWID identifies the current logical unit of work for conversations with a syn- 
chronization level of none or confirm. 


1 This information is valid only for some of the communications types. These fields will be blank if the information does not pertain to the 


communications type you are using. 
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Sending and Receiving Data 


Data is sent between systems by using output (or write) and 
input (or read) operations. The read and write operations are 
done using a record format. The results of read and write 
operations are communicated to the program with ICF mes- 
sages, major/minor return codes, high-level language status 
values, and an I/O feedback area. 


The I/O feedback area is updated for every read/write opera- 
tion. The I/O feedback area consists of two sections: 


The common I/O feedback area contains information 
relevant to all communications types. 


The file-dependent I/O feedback area contains infor- 
mation that can apply to one or more of the communica- 
tions types. 


Common I/O Feedback Area 


The common I/O feedback area contains information in the 
following fields: 
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Output operation count. A count of the number of suc- 
cessful output operations. This count is updated only 
when an output operation completes successfully. 


Input operation count. A count of the number of suc- 
cessful input operations. This count is updated only 
when an input operation completes successfully and 
data is received. 


Output then input operation count. A count of the 
number of successful output then input operations. 


Count of other operations. A count of the number of 
successful operations other than output and input oper- 
ations (such as acquire and release operations). 


Current operation. A hex value representing the 
current (last requested) operation, sent as follows: 


Hex 01 Input 

Hex 05 Output 

Hex 06 Output then Input 
Hex 11 Release 

Hex 12 Acquire 


Record format name. Name of the record format just 
processed. The record format is either specified on the 
I/O request or determined by the specified format 
selection processing option. 


Device class and type. A hex code representing a 
device class for ICF and the communications type used 
as follows: 


Hex OBOE APPC 
Hex 0B20 SNUF 
Hex OBOA BSCEL 
Hex OB1F Asynchronous 
Hex OB1E Intrasystem 
Hex 0B42 Finance 
Hex 0B43 Retail 
ICF Programming V4R1 


Program device name. The program device name to 
which the last operation was issued. 


Record length. The record length of the last I/O opera- 
tion based on the record format processed, not including 
any indicators or program-to-system fields (P-data 
fields). 


Blocked record count. The number of records sent or 
received on an I/O operation. For ICF, the value is 
always 1. 


Record length. The record length of the last I/O opera- 
tion based on the record format processed, including 
indicators and P-data. 


File-Dependent I/O Feedback Area 


The file-dependent I/O feedback area contains information in 
the following fields: 


Actual record length. On input, this is the actual length 
of user data received from the remote system or device. 
When the data received is longer than the data 
requested (all the received data cannot be contained in 
the record format used), the length of data is provided, if 
known. If the actual length cannot be determined, the 
field is set to hex FFFFFFFF. When a partial record is 
received (the remainder of the record is never sent), the 
length of the data received is provided. If the input oper- 
ation completes with an error (other than partial record 
or truncated record), the contents of the field are unpre- 
dictable. 


On output, the actual length is the length of data moved 
from the user's buffer to the output buffer to send to the 
remote system. If the output operation completes with 
an error, the contents of the field are undetermined. 


ICF major/minor return code. A 4-character code (2 
characters representing the major code, 2 characters 
representing the minor code) indicating the results of 
each operation. 


Negative response error data. For some return codes, 
this field contains more detailed information about the 
reason for the error. Refer to the following books: 


APPC Programming 

Finance Communications Programming 
SNA Upline Facility Programming 
Retail Communications Programming 


for more information on this field, depending on what 
communications type you are using. 


Request-to-write indication. This indication tells you if 
the remote system requested that the application 
program stop sending data and give permission (by 
issuing a read or an allow-write request) to the remote 
system to begin sending. 


Remote format name. The remote format name 
received from the program device on an input operation. 
This is valid when the FMTSLT option on the 
ADDICFDEVE or OVRICFDEVE command is *RMTFMT. 


See Chapter 6 for more information on the FATNAME 
DDS keyword. 


¢ Mode. Mode associated with the program device. 
Mode is for APPC only. Refer to the APPC Program- 
ming book for more information on modes. 


¢ Safe indicator. This field shows that an end-of-text 
(ETX) control character has been received in the buffer, 
and it is only valid for BSCEL. The safe indicator is not 
set if BLOCK(*USER) was specified on the 
ADDICFDEVE or OVRICFDEVE command. Refer to the 
BSC Equivalence Link Programming book for more infor- 
mation on this indicator. 


Refer to Appendix C for a summary of the fields and the 
communications types to which the information applies. 
Refer to the appropriate communications programming book 
for specific details on pertinent fields. 


Like the open feedback area, the support provided by the 
high-level language you use determines whether you can 
access this information. 


Checking Return Codes 


After each operation, an ICF return code is returned to your 
program. Your program checks this return code to deter- 
mine: 


e The status of the operation just completed 
e The operation that should be done next 


It is recommended that your program check these return 
codes at the completion of every operation to ensure that the 
operation completed successfully or that the appropriate 
recovery action is taken. 


A summary of these return codes is described in 

Appendix B. These codes, or groups of codes, are also con- 
verted to language return codes. For example, the ICF 
codes are converted to RPG *STATUS values or to ILE 
COBOL file status values. The ILE C programming language 
does not have file status values. These values are shown in 
a chart in the appropriate language chapter of this book. 


Each ICF return code consists of a 2-digit major code and a 
2-digit minor code. The major code identifies the general 
condition for a group of return codes, and is usually sufficient 
to determine the action to be taken. The minor code identi- 
fies the specific condition and may indicate the specific 
action that should be taken next. For example: 


8233 
| | 


| Minor code 


Major code 


In this example the major code 82 indicates that an acquire 
or open operation was not successful. The minor code 33 
indicates that the operation failed because an ADDICFDEVE 
command or OVRICFDEVE command was not issued for the 
program device you are trying to acquire. 


Usually, your program determines the action to take by 
checking only the major code or the language status code. 
However, you may need to check minor codes for specific 
conditions that occur for your particular application or com- 
munications configuration. 


For more information about major and minor return codes, 
refer to Chapter 8. 


Writing to a Program Device 
Use a write operation to send data to the remote system. 


The ICF file supports a set of DDS processing keywords and 
system-supplied formats, used in conjunction with the write 
operation, to perform various communications functions. 
Refer to Chapter 6 and Chapter 7 for more information 
about specifying the communications function to be used with 
the write operation. 


Note: Data can be written to only one program device for 
each write operation. 


Figure 5-3 on page 5-8 shows the use of the write operation 
when sending data. 


Your program uses a write operation to send data to 
the remote system. 


Fs Your program receives a return code indicating the 
completion status of the operation. 


If a successful return code is received, your program 
continues sending several records. 


Inviting a Program Device 


Your program indicates it wants to start an asynchronous 
input operation by inviting a program device. The invite func- 
tion prepares your program to receive data. Your program 
can continue processing after issuing the invite request, and 
does not have to wait for the data. 


An invite function is specified by: 


e Issuing a write operation to a program device using a 
record format with the INVITE DDS keyword in effect. 


e Issuing a write operation to a program device using a 
system-supplied format whose definition contains the 
invite function. 


For more information about specifying the invite function, see 
Chapter 6 and Chapter 7. 
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Figure 5-3. Using Write Operation When Sending Data 


You can receive the response from an invited program 
device by doing an input operation. See “Reading from 
Invited Program Devices” on page 5-10 and “Reading from 
One Program Device” on page 5-14 for more information. 


At least one program device must be invited before a read- 
from-invited-program-devices operation can return a 
response from a program device. 


A program would invite a program device because: 


e Inviting several program devices allows the program to 
do a read-from-invited-program-devices operation and 
receive data from one of the invited program devices 
with a response available. Therefore, using the invite 
function of the ICF file, the program can handle receiving 
a record from any one of several invited program 
devices by reading from a single point in the program. 
The program issues an input operation for the response. 


e¢ A program wants to use the time-out capability of the 
read-from-invited-program-devices operation. 


Format Selection Processing 


The format selection (FMTSLT) parameter on the 
ADDICFDEVE and OVRICFDEVE commands determines 
how ICF data management selects the record format to use 
when receiving data with the read and read-from-invited- 
program-devices operations. The three different methods of 
selecting a record format are discussed here. The name of 


the record format selected is placed in the I/O feedback area. 
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Refer to “Determining the Record Format Returned” on 
page 5-14 for more information about determining the record 
format selected. 


Program Selection (*PGM): If you specify 
FMTSLT(*PGM), which is the default, on the ADDICFDEVE 
or OVRICFDEVE command, your program must specify the 
record format to use when your program does an input oper- 
ation. If no record format name is given, ICF data manage- 
ment uses the default record format. The default format is 
always the first format defined in the file. 


The only selection process that is applicable when using the 
system-supplied QICDMF file is FMTSLT(*PGM). The 
default record format in this file is a 4096-byte data record 
called DFTRCD. You should either specify this format on the 
input operation or allow the system to default. Your program 
must then examine the input data to determine what data 
processing to perform on the fields in the record. 


Record-ldentifier Selection (*RECID): Selecting 
FMTSLT(*RECID) on the ADDICFDEVE or OVRICFDEVE 
command provides a means of identifying and selecting the 
record format to use based on the data received. If you 
specify FMTSLT(*RECID), the file is searched for the RECID 
keyword on each input operation. The RECID keyword pro- 
vides a definition for determining which record format to use. 


When you specify the RECID keyword, you define a compare 
value. You must define the beginning position in the record 
format and the compare value to use. When data is 
received, the corresponding positions in the record are com- 


pared to the defined RECID values. When a match is found, 
that record format is used to process the received data. If no 
match is found, or if no data is received, the default record 
format is used. 


When the FMTSLT(*RECID) is specified, the default format 
for an ICF file is one of the following: 


e The first format in the file without the RECID keyword 
specified 


e The first format in the file if all formats have the RECID 
keyword specified (applies only when no data is 
received) 


Notes: 


1. An ICF return code of 81E9 is returned to your program 
if the default format has the RECID keyword specified 
and no match is found for the received data. Refer to 
Appendix B for a complete list of return codes. 


2. lf aread with a record format specified is issued, the 
format specified must match the name determined by 
the RECID keyword selection process. If not, return 
code 3441 is returned to your program. 


Refer to Chapter 6 for more information about the RECID 
keyword. 


Remote Format Selection (*RMTFMT): Remote 
format selection is supported by APPC and intrasystem com- 
munications. 


If you specify FMTSLT(*RMTFMT) on the ADDICFDEVE or 
OVRICFDEVE command, your program does not need to 
enter a format name when it does an input operation. 
Instead, the format name passed with the data from the 
Summary of Format Selection Processing: 

Figure 5-4 summarizes the record format that is selected 
based on the format selection option specified on the 
FMTSLT parameter and the record format name specified on 
the input operation (if one was specified). This chart also 
shows what return codes can result from the format selection 
process on an input operation. 
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remote program is used. If the remote system is an AS/400 
system, the remote program must specify the FMTNAME 
keyword in the record used to send the data to ensure the 
format name is sent. 


If the remote system does not send a format name (for 
example, a record is sent without a FMTNAME keyword 
specified) and a format name is specified with the input oper- 
ation in your program, that name is used to process the data 
received. If no format name is specified on the input opera- 
tion, the default record format in the ICF file is used. The 
default record format is the first record format in the file. 


If the remote program sends a format name and your 
program specifies a format name, the names must match. If 
they do not match, return code 3441 is returned to your 
program. 


If the remote program sends a format name and 
FMTSLT(*RMTFMT) was not specified on the ADDICFDEVE 
or OVRICFDEVE commands, the remote format name sent 
is ignored by ICF. 


The record format name received from the remote system on 
a successful input operation is put in the file-dependent 
section of the I/O feedback area. The high-level language 
may access this area to determine the remote record format 
name received from the remote system. Refer to the appro- 
priate language reference book for more information about 
accessing the I/O feedback area. 


Record Format Name Not 


selection. 


program. 


format selected. Otherwise, return code 83E0 returned to 


FMTSLT Specified on Input Opera- 
Option Input Data Record Format Name Specified on Input Operation tion 
*PGM Does not apply to format If specified format name is defined in ICF file, specified Default format! selected. 
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Figure 5-4 (Page 2 of 2). Format Selection Options 


Record Format Name Not 

FMTSLT Specified on Input Opera- 

Option Input Data Record Format Name Specified on Input Operation tion 

*RECID Data received matches If matched format is same as specified format, matched Matched format selected. 
record format in file with format selected. Otherwise, return code 3441 returned to 
RECID keyword. program. 

Data received does not If default format2 does not have RECID keyword, default If default format2 does not 

match any record in file format selected. Otherwise, return code 81E9 returned to have RECID keyword, 

with RECID keyword. program. default format selected. Oth- 
If format selected (default2) is not same as specified Sa eeg code 81E9 
format, error return code 3441 returned to program. returned: (0: Program. 

No data received. If default format2 is same as specified format, default Default format2 selected. 
format selected. Otherwise, return code 3441 returned to 
program. 

*RMTFMT Record format name If remote format name is defined in the ICF file, remote If remote format is defined in 
(remote format) received format selected. Otherwise, default 1 format selected. the ICF file, remote format 
from the remote system If format selected is not same as specified format, return ee aoe default 

code 3441 returned to program. Oral «Sele ceo: 
Record format name If specified format name is defined in the ICF file, specified Default format! selected. 
(remote format) not format selected. Otherwise, error return code 83E0 
received from the remote returned to program. 
system 


1 The default record format for FMTSLT(*PGM) and FMTSLT(*RMTFMT) is the first record format in the ICF file. 


2 The default format for FMTSLT(*RECID) is the first record format in the ICF file that does not have a *RECID keyword specified, or the 
first record format if all record formats have the *RECID keyword specified. 


Reading from Invited Program Devices 


The primary purpose of the read-from-invited-program- 
devices operation is to provide a single point in the program 
at which the program can wait for and receive a record from 
one of several program devices. The read-from-invited- 
program-devices operation can wait for and return a record 
to the program from one of the invited program devices with 
an available record. 


The read-from-invited-program-devices operation is also used 
to check whether the timer that was set by the timer function 
has ended. Refer to Chapter 6 and Chapter 7 for more 
information on the timer function. 


The read-from-invited-program-devices operation can com- 
plete when: 


¢ Acomplete record arrives for an invited program device. 
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e A communications failure is detected on one of the 
invited program devices. 


e The job is being canceled (controlled). 


e The time specified by either the timer function or the 
WAITRCD parameter on the CRTICFF command is 
reached. 


The read-from-invited-program-devices operation is only valid 
if the high-level language you are using considers the ICF file 
to be a multiple device file. The ILE C, ILE COBOL, and ILE 
RPG languages consider the ICF file to be a multiple device 
file, while the FORTRAN/400 language does not. See the 
appropriate language reference book for more information. 


Figure 5-5 on page 5-11 shows how you can use the invite 
function and read-from-invited-program-devices operation to 
receive data from two different program devices. 
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Figure 5-5. Using the Invite Function and Read-from-Invited-Program-Devices Operation to Receive Data 


Your program uses the invite function to ask the 
remote system to send data for program device 
PGMDEVA. 


A successful completion return code tells your program 
that ICF data management received the operation and 
is asking the remote system to send data. No data 
has yet been received. 


Your program issues another invite function. This 
invite is for program device PGMDEVC. Data has not 
yet been received for the first invite for program device 
PGMDEVA. 


The system receives data for program device 
PGMDEVA. (Data is not necessarily received in the 
order in which the invite functions were issued. For 


ou 4a 


example, data can be received for program device 
PGMDEVC before data is received for PGMDEVA. 
Your program must check the program device name to 


determine for which program device the data is 
received.) 


fA read-from-invited-program-devices operation is used 


to receive the data sent. 


[J This time a successful completion return code tells 
your program that data has been received and is in 


your program buffer. 


co =] 


device PGMDEVA data. 
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Data is received for program device PGMDEVC. 


Another invite function is used to ask for program 
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EJ Another read-from-invited-program-devices operation is 
used to receive the data for program device 
PGMDEVC. 


Specifying Maximum Wait Interval: You can specify 
the maximum amount of time your program will wait for a 
read-from-invited-program-devices operation to complete. 
The time interval can be specified by: 


¢ Specifying the WAITRCD parameter on the CRTICFF, 
CHGICFF, and OVRICFF commands 


e Issuing the timer function 


The WAITRCD parameter establishes the maximum time 
interval used for all read-from-invited-program-devices oper- 
ations issued against the file. 


AS/400 System 


The timer function is used to specify the maximum time 
interval used for read-from-invited-program-devices oper- 
ations until either the timer ends or a new interval is set 
using the timer function. When the interval for the timer 
operation is in effect, the value specified on the WAITRCD 
parameter is ignored. 


If a response is not received from the invited program 
devices within the specified amount of time, the program is 
notified with an ICF return code (0310) indicating that the 
timer interval has ended. 


Figure 5-6 shows the relationship between the timer function 
and the read-from-invited-program-devices operation. 
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Figure 5-6. Relationship between Timer and Read-from-Invited-Program-Devices Operations 


F¥ = Your program issues an invite function. 
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fA successful completion return code tells your program 
that ICF data management accepted the request and 
that the remote system is expected to respond. No 
data has yet been received. 


Your program uses the timer function to set the 
maximum length of time to wait for a response. 


EJ A read-from-invited-program-devices operation is used 
to read the data or, if the data is not received within 
the length of time specified, the return code indicates 
that the time you set has elapsed. 


Es The data is received before the time elapses. There- 
fore, a successful completion return code is passed to 
the program with the response from the remote 
system. 


G@ Your program again uses the invite function to send 
data and ask for a response. The time interval is again 
set, and another read-from-invited-program-devices 
operation is issued. 


This time the read-from-invited-program-devices opera- 
tion results in a return code that tells your program the 
time elapsed before a response was received from the 
remote system. When this happens, you may want to 
send a message to the operator, continue processing, 
or both. 


The ILE COBOL programming language provides a means of 
calling the read-from-invited-program-devices operation as if 
WAITRCD(*IMMED) is specified. Refer to the ILE 
COBOL/400 Reference book for information about the NO 
DATA phrase of the READ statement. See “Determining the 
Wait-for-Record Value” on page 4-5 for information about 
specifying the WAITRCD parameter. 


Note: WAITRCD has no meaning to the FORTRAN/400 lan- 
guage, since the read-from-invited-program-devices operation 
is not supported. 


Refer to Chapter 6 and Chapter 7 for information on speci- 
fying the timer function. 


Responses: A program can receive one of many 
responses from the read-from-invited-program-devices opera- 
tion. These responses are communicated to your program 
through an ICF return code. 


The ICF file also supports a set of DDS response indicators 
that can be used in conjunction with the read-from-invited- 
program-devices operation to indicate status information 
about the operation. Refer to Chapter 6 for more information 
about response indicators. 


The following sections describe possible responses from the 
read-from-invited-program-devices operation and the condi- 
tions under which the program receives the response. 


Data from One of the Invited Program Devices with Data 
Available: \f at least one invited program device has data 
available and the job has not been ended (controlled), the 
read-from-invited-program-devices operation returns data 
from one of the invited program devices. 


After the read-from-invited-program-devices operation com- 
pletes, the program can examine feedback that allows it to 
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identify the program device that returned the data and the 
record format of the data returned. See “Determining Which 
Invited Program Device Had Data Available” on page 5-14 
for information about how to determine which program device 
responded. See “Determining the Record Format Returned” 
on page 5-14 for information about determining the format of 
the returned record. 


The program device returning the data is no longer in the 
invited state. The program device must be invited before it 
can return any more data using the read-from-invited- 
program-devices operation. Other invited program devices 
remain invited. 


Job Ended (Controlled): The read-from-invited-program- 
devices operation returns this response if the job is ended 
(controlled) before or during the wait for data to become 
available from an invited program device. 


Receiving the job ended response does not cancel the invite. 
All invited program devices remain invited. 


If any program in the job is notified that the job is being 
ended (controlled), that program should notify all other pro- 
grams in the job. The system notifies only one program 
regardless of how many ICF files are used in the job. 


When a program receives a job ended (controlled) indication, 
the program should complete operations and end before the 
system changes the job ended (controlled) to job ended 
(immediate) and forces all processing to stop. This action is 
important if a program needs to complete some processing 
before it ends. 


No Invited Program Devices Have Data Available: The 
read-from-invited-program-devices operation returns this 
response when the job is not being ended and: 


e At least one program device is invited. 


e No data is available from any of the invited program 
devices. 


e The WAITRCD(*IMMED) parameter is specified. 
All invited program devices remain invited. 


Time-Out on Wait for Data from Invited Program 
Devices: The read-from-invited-program-devices operation 
returns this response when: 


e No data is available from any of the invited program 
devices in the amount of time specified as the 
WAITRCD parameter or the timer function. 


e The job is not being ended. 
All invited program devices remain invited. 


No Program Devices Invited: \f no program devices are in 
the invited state and the timer function is not in effect, the 
program is notified that no program devices were invited. 
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Error from One of the Invited Program Devices: The 
read-from-invited-program-devices operation can return an 
error condition instead of data from one of the invited 
program devices if: 


e The job is not being ended. 
e Atleast one invited program device has a response 
available. 


If an invited program device detects an error while it does the 
input operation, the error (like the data) is held until the 
program device is read using a read-from-invited-program- 
devices or read operation. 


Determining Which Invited Program Device Had 
Data Available: After a read-from-invited-program-devices 
operation returns data from an invited program device, the 
program may need to identify the name of the program 
device from which the data was returned. This identification 
is necessary if the program wants to handle one program 
device differently from other program devices. 


The program can determine the name of the program device 
that returned the data from a field in the I/O feedback area. 
Refer to the appropriate language reference book to learn 
about other ways to get this information, and about how to 
access the I/O feedback area. 


If the program needs the name of the program device that 
returned the data, the program must get that information 
before doing any other I/O operations to the file. 


If the read-from-invited-program-devices operation did not 
return a data available response (some other response, like 
job ended (controlled) was returned to the program), the field 
containing the name of the program device to which I/O was 
last directed in the I/O feedback area is set to *N (not appli- 
cable). 


Determining the Record Format Returned: Because 
a read-from-invited-program-devices operation returns a 
record from one of the invited program devices with an avail- 
able record, regardless of that record’s format, you cannot 
specify a record format on the read-from-invited-program- 
devices operation. 


The system uses the FMTSLT parameter on the 
ADDICFDEVE, CHGICFDEVE, and OVRICFDEVE com- 
mands to determine the record format. Therefore, the 
program may have to determine the format of the record 
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returned before handling the record (if a program device can 
return a record in one of several record formats). 


The program can determine the record format of the data 
returned from a field in the I/O feedback area that indicates 
the name of the last record format used for I/O. Refer to the 
appropriate language reference book to learn about other 
ways of getting this information and about how to access the 
I/O feedback area. 


Note that if the program needs the name of the record format 
used to receive the data, the program must get that informa- 
tion before doing any other I/O operations to the file. 


Reading from One Program Device 


A read operation waits for and receives data from one 
program device. There is no time limit on a read operation 
(the WAITRCD parameter and the interval specified on a 
timer function are ignored). The program waits until data is 
available from that program device. The read operation 
differs from the read-from-invited-program-devices operation 
in that a read operation is directed to a specific program 
device, whereas the read-from-invited-program-devices oper- 
ation receives data from any program device that was previ- 
ously invited. 


Note: When a program device is invited, it is recommended 
that a read-from-invited-program-devices operation be per- 
formed rather than a read operation to receive data. Perfor- 
mance may be degraded if your program issues multiple 
read operations to invited program devices. 


The program can indicate to the system that a read operation 
must be done in three ways: 


e Explicitly, by specifying the name of a program device 
on the read operation 


e Implicitly, by specifying the name of a record format on 
the read operation 


e Implicitly, by specifying neither a record format or 
program device name, and the high-level language con- 
siders the ICF file a single device file 


Because you cannot specify a record format on a read-from- 
invited-program-devices operation, the system interprets a 
read with a record format specified as a read operation. See 
the appropriate language reference book for information 
about calling the read operation explicitly or implicitly and 
about which program device is used if the read operation is 
implicitly called. 
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Figure 5-7. Using the Read Operation 


Figure 5-7 shows how to use the read operation. 


F¥ = Your program uses a write operation to send data to 
the remote system. 


1 sAread operation is then issued to receive data from 
PGMDEVA. The program waits to receive the data 
before continuing. 


If the program device specified on the read operation has 
been invited, the invite is satisfied and the input operation 
started when the program device was invited is completed 
before control is returned to the program. 


The ICF file supports a set of DDS response indicators that 
can be used in conjunction with the read operation to indi- 
cate status information about the operation. Refer to 
Chapter 6 for more information about response indicators. 


Writing and Then Reading from One 
Program Device 


Some high-level languages support an interface to send a 
single I/O operation that does a write operation followed by a 
read operation to a program device. 


The same record format is used on both the write and read 
operation. 
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Canceling an Invite of a Program Device 


If a program device is invited, it is possible to cancel the 
invite: 
e Explicitly, by issuing a cancel-invite function to the 
program device 


e Implicitly, by issuing a write operation to the program 
device 


Refer to Chapter 6 and Chapter 7 for information about 
specifying the cancel-invite function. 


Waiting for a Display File, an ICF File, and 
a Data Queue 


You can use data queues for a program that waits for data 
on a display file, an ICF file, and a data queue at the same 
time (in any combination). When you specify the DTAQ 
parameter for certain commands, you can indicate a data 
queue that will have entries placed on it when any of the fol- 
lowing occurs: 


e An enabled function key or the Enter key is pressed 
from an invited display device. 


¢ Data becomes available from an invited ICF session. 
e A user-defined entry is made to the data queue by a job 
running on the system. 
The commands that allow you to indicate a data queue with 
the DTAQ parameter are: 


¢ Create Display File (CRTDSPF) 
e¢ Change Display File (CHGDSPF) 
¢ Override Display File (OVRDSPF) 
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¢ Create ICF File (CRTICFF) 
¢ Change ICF File (CHGICFF) 
¢ Override ICF File (OVRICFF) 


By using the IBM-supplied QSNDDTAQ program, jobs 
running on the system can also place entries on the same 
data queue as the one specified in the DTAQ parameter. 


For an ICF or display file, the application program uses the 
IBM-supplied QRCVDTAQ program to receive each entry 
placed on the data queue and then processes the entry 
based on whether it was placed there by the display file, the 
ICF file, or the QSNDDTAQ program. For a display file, the 
application then issues a read or read-from-invited-devices 


operation to receive the data. For more information on the 
QRCVDTAQ function and syntax, and examples of waiting 
on one or more files and a data queue, see the CL Program- 
ming book. 


The display file and ICF file entry that is put on the data 
queue is 80 characters in length and contains the field attri- 
butes described in Figure 5-8. Therefore, the data queue 
that is specified using the commands listed above must have 
a length of at least 80 characters. 


Entries placed on the data queue by jobs using QSNDDTAQ 
are defined by the user. 


Figure 5-8. Display File and ICF File Entry Field Attributes 


Position Data Type Meaning 


1 through 10 Character 


*ICFF (ICF file) 
*DSPF (display file) 


The type of file that placed the entry on the data queue. This field can have one of two values: 


If the job receiving the data from the data queue has only one display file or one ICF file open, then 
this is the only field that needs to be used to determine what type of entry has been received from the 


data queue. 
11 through 12 Binary 


Unique identifier for the file. The value of the identifier is the same as the value in the open feedback 


area for the file. This field should be used by the program receiving the entry from the data queue only 
if more than one file with the same name is placing entries on the data queue. 


13 through 22 Character 


The name of the display or ICF file. This is the name of the file actually opened after all overrides 


have been processed, and is the same as the file name found in the open feedback area for the file. 
This field should be used by the program receiving the entry from the data queue only if more than one 
display file or ICF file is placing entries on the data queue. 


23 through 32 Character 


The library where the file is located. This is the name of the library after all overrides have been 


processed, and is the same as the library name found in the open feedback area for the file. This field 
should be used by the program receiving the entry from the data queue only if more than one display 
file or ICF file is placing entries on the data queue. 


33 through 42 Character 


The program device name after all overrides have been processed. This name is the same as that 


found in the program device definition list of the open feedback area. For file type *DSPF, this is the 
name of the display device where the command was entered or the Enter key was pressed. For file 
type *ICFF, this is the name of the program device where data is available. This field should be used 
by the program receiving the entry from the data queue only if the file that placed the entry on the data 
queue has more than one device or session invited prior to receiving the data queue entry. 


43 through 80 Character Reserved. 


Releasing a Program Device 


You can explicitly release a program device from an ICF file 
by using the release operation, or you can implicitly release 
the device by closing the file. 


If you release the program device, you must reacquire it 
before you can use it again for I/O operations. 


The release operation ends the session only when certain 
criteria are met. The end-of-session function always ends 
the session. Refer to Chapter 6 and Chapter 7 for more 
information about specifying an end-of-session function. 
The following processing is done by the release operation: 


e Source program 
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— If the program device is invited, the release opera- 
tion fails. 


— Ifa transaction is still active on the session, the 
release operation fails. 


— Ifa transaction is not active on the session, the 
session ends. 


— lf the device description associated with the 
program device is allocated when the program 
device is acquired, it is deallocated when the 
program device is released. 


— lf an error occurs due to the hardware or an SNA 
protocol violation, the release operation fails. 


e¢ Target program 


— The release operation severs the logical connection 
between the application and the requesting program 
device. The session is not ended. 


— The program (or another program in the same job 
structure) can reestablish the connection to the 
same session by acquiring the requesting program 
device. The communications session, including the 
state of the session, remains intact. 


Closing an Intersystem Communications 
Function File 


The processing done by the close operation depends on 
whether the file is shared. If the file is not shared, the fol- 
lowing processing is done: 


e All sessions associated with the source program are 
ended. 
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e All sessions associated with the target program are 
released. 


e The file resources allocated by the open operation are 
deallocated and returned to the system. 


If the file is shared, the program cannot do I/O operations to 
the file. Other programs that have the file open can still use 
the file. 


If the close operation is successful, an open operation is the 
only program operation allowed to the file. If the close oper- 
ation fails, the program should call the close operation a 

second time. A second close operation is always successful. 


Summary 
Figure 5-9 on page 5-18 shows the relationship between the 


program, the ICF file, and the communications configuration 
on a local and remote AS/400 system. 
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apply to APPC only. 


2. Network interface description applies only to ISDN. 
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Remote System 


Local System 


The source program: 


Opens the file 
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The source program is your ILE C, ILE COBOL, or ILE RPG 
application, which is communicating with the target program 
through an ICF file. You can create this file using the 
CRTICFF command, and change it using the CHGICFF or 
OVRICFF command. 


e Acquires one or more program devices (Only one is 
allowed per ICF file for FORTRAN/400 applications.) 


e Reads and writes to program devices in the file to 
receive and send data 


e Releases the acquired program devices 
¢ Closes the file 
The device entries defined in the file with the ADDICFDEVE, 
CHGICFDEVE, or OVRICFDEVE command provide: 
e Mapping to the communications configurations 
¢ Communications-type-dependent definitions of program 
device attributes 


The local configurations selected by the program device 
entry define the connection to the remote system. 


Remote System 


An incoming program start request from the local system 
starts a target job. 


The target program is your ILE C, ILE COBOL, or ILE RPG 
application, which is communicating with the source program 
through an ICF file. You can create this file using the 


CRTICFF command and change it using the CHGICFF or 
OVRICFF command. 
The target program: 

¢ Opens the file 


e Acquires the requesting program device (This must be 
done implicitly on the open for FORTRAN/400 pro- 
grams.) 


e Reads and writes to the requesting program device for 
the file to receive and send data 


e Releases the requesting program device (This must be 
done implicitly on the close for FORTRAN/400 pro- 
grams.) 


¢ Closes the file 
The device entries defined in the file with the ADDICFDEVE, 
CHGICFDEVE, or OVRICFDEVE command provide: 
e A relationship to the requesting program device 
¢ Communications-type-dependent definitions of program 
device attributes 


Refer to “Remote Program Start Considerations” on 
page 8-5 for more information on subsystems. 
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Figure 5-10 shows how the program, file, and configuration 
names are mapped to each other in ILE C programming lan- 
guage. 
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tinclude <stdio.h> 
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Figure 5-10. ILE C Program, File, and Configuration Mapping 
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You create various configuration objects when you use the 
communications configuration function. The remote location 
name provides the primary mapping between the program 
device and the communications configurations. The speci- 


Create COBOL/400 Program 


fied remote location name is used to select the device 
description. 


Figure 5-11 shows how the program, file, and configuration 
names are mapped to each other in the COBOL/400 pro- 
gramming language. 


SELECT ICFFILE ASSIGN TO WORKSTATION-ICFFILE 


FD ICFFILE. 


| | 


ACQUIRE "PGMDEVA" FOR ICFFILE. 


WRITE ICF-BUFFER 


FORMAT IS "RECORD", 


TERMINAL IS "PGMDEVA" 


READ ICFFILE 


Create ICF File 


CRTICFF FILE(ICFFILE)... 


7 


ADDICFDEVE FILE(ICFFILE) PGMDEV(PGMDEVA) RMTLOCNAME (CHICAGO) 


Create Communications sabe 2 


Remote location 


Local location 


Network ID 


Figure 5-11. COBOL/400 Program, File, and Configuration Mapping 
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You create various configuration objects when you use the 
communications configuration function. The remote location 
name provides the primary mapping between the program 
device and the communications configurations. The speci- 


fied remote location name is used to select the device 
description. 


Figure 5-12 shows how the program, file and configuration 


names are mapped to each other in RPG/400 programming 
language. 


Create RPG/400 Program 


You create various configuration objects when you use the 
communications configuration function. The remote location 
name provides the primary mapping between the program 
device and the communications configurations. The speci- 


fied remote location name is used to select the device 
description. 


FICFFILE 

F KID DEVICE 
F \ KNUM 2 

C | "PGMDEVA' ACQ ICFFILE 


MOVEL'PGMDEVA' 


READ RECORD 


Create ICF File 
CRIICFF FILE(ICFFILE)... 


. 


READ ICFFILE 


DEVICE 10 


ADDICFDEVE FILE(ICFFILE) PGMDEV(PGMDEVA) RMTLOCNAME (CHICAGO 


Create Communications Configurations 


Remote location 
Local location 


Network ID 


Figure 5-12. RPG/400 Program, File, and Configuration Mapping 
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Chapter 6. Using Communications DDS Keywords 


This chapter explains how to use data description specifica- 
tions (DDS) keywords on input and output operations to 
perform communications functions with the remote system. 
These DDS keywords are associated with the defined record 
format used on the read or write operation. The record 
formats associated with the DDS source for your ICF file are 
referred to as user-defined formats. This is in contrast to the 
system-supplied formats discussed in Chapter 7. It is 
assumed that you have opened your file and established 
your session as described in Chapter 5. 


The information and illustrations provided describe the func- 
tion of each of the processing keywords supported by the 
ICF file. Although all of the parameters supported by each 
keyword are described, the information on coding the 
keywords is found in the DDS Reference book. The DDS 
Reference book also contains general information on defining 
record formats. 


You can use several DDS keywords and combinations of 
keywords on a single input/output (I/O) operation. 

Figure 6-19 on page 6-23 shows the processing sequence 
when multiple DDS keywords are specified together. 


All the keywords described in this chapter may not be sup- 
ported by the communications type you are using. Further- 
more, some keywords may operate differently depending on 
the communications type. Figure 6-17 on page 6-21 and 
Figure 6-18 on page 6-22 summarize the support provided 
by each communications type. Refer to the appropriate com- 
munications programming book for the communications type 
you are using for more detail about supported keywords. 


Several DDS keywords that do processing-control, refer- 
encing, and text-definition functions that are valid in ICF files 
and other types of files are not discussed in this book. 

These keywords are ALIAS, FLTPCN, INDARA, INDTXT, 
REF, REFFLD, and TEXT. Refer to the DDS Reference 
book for more information on how to code and use these 
keywords. These keywords are supported by all communica- 
tions types. 


Examples of source DDS and the commands used to create 
and use an ICF file are found at the end of this chapter. 


Refer to Chapter 10 for complete program examples that use 
DDS keyword processing. 


You can use system-supplied communications formats 
instead of DDS keywords to do communications-specific 
functions. Refer to Chapter 7 for more information on 
system-supplied formats. 
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Starting a Program on the Remote System 


Your program must specify the target program it will commu- 
nicate with before it can send or receive data. The target 
program is started by specifying an output operation with the 
EVOKE keyword in effect. Generally, the necessary parame- 
ters to identify the target program you want to start must be 
specified. However, for some communications types, these 
parameters are not required. 


These parameters include items such as the program name, 
the name of the remote library where the program is stored, 
and security information (when required). You may also 
include data with the evoke function, which will be sent to the 
target program when the evoke function is done. A program 
start request is sent to the remote system when your 
program issues the evoke function (unless, for APPC appli- 
cations, the evoke is delayed by specifying the DFREVOKE 
keyword). 


Use the EVOKE, SECURITY, and SYNLVL keywords to start 
a program at the remote system. 


Evoke (EVOKE, DFREVOKE, SECURITY, 
and SYNLVL) 


The EVOKE keyword allows your program to start a program 
on the remote system. EVOKE is valid only when the source 
program is not already communicating with the target 
program on the same transaction. 


The format of the EVOKE keyword is: 


EVOKE([library-name/]program-name [parameter-1... 
[parameter-255]]) 


The program-name parameter is required on the EVOKE 
DDS keyword to identify the program to be started on the 
remote system. However, some communications types do 
not require the program name. In these cases, blanks 
should be used for the program name instead. Refer to the 
appropriate communications book to determine if the commu- 
nications type you are using requires a program name on the 
EVOKE DDS keyword. 


The optional library-name parameter specifies the library 
where the program is stored on the remote system. In 
general, it is best to specify the library separate from the 
program. lf you specify the target program as a single literal, 
then it must be specified in the format required by the remote 
system or in the architected format. For example, if you are 
using APPC with another AS/400 system, the program name 
can be in the form /ibrary/program or program.library. \f the 
remote system is an AS/400 system and a library name is 
not given, the library list for the subsystem that is handling 
the request on the remote system is searched for the 
program name. The library list for the subsystem consists of 
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the values from the QSYSLIBL and QUSRLIBL system 
values at the time the subsystem was started. 


In addition to passing the program-name and library-name to 

the remote system, you can also use the EVOKE DDS 

keyword to send up to 255 user-defined parameters to the 

remote system. (Some communications types do not support 

255 parameters. Refer to the appropriate communications 

programming book for any additional restrictions.) The target 

program defines the number and format of the parameters. 

If the remote system is another AS/400 system, the following 

apply: 

e The parameters are passed to the program as if they 

were passed from a Call a Program (CALL) command. 


e If the parameters contain embedded commas, the 
remote AS/400 system considers these to be multiple 
parameters rather than a single parameter. 


Any transaction status information sent by the source 
program is received on the first read operation of the target 
program. For example, if the target AS/400 system program 
is started from an AS/400 system with an evoke-with-invite 
function using advanced program-to-program communica- 
tions (APPC), the first read operation on the target program 
completes with an 0300 (change direction received) 
major/minor return code. 


DFREVOKE Keyword: You can use the DFREVOKE 
DDS keyword to delay sending a program start request until 
the output buffer is full of data or until the output buffer is 
flushed, using the FRCDTA or CONFIRM keyword, for 
example. 


The DFREVOKE keyword is valid only for APPC and used 
only for specialized applications that must have data sent 
with the EVOKE keyword. See the APPC Programming 
book for more information. 


SECURITY Keyword: You can use the SECURITY DDS 
keyword to include security information with the evoke 
request. The SECURITY keyword is only valid in conjunction 
with the EVOKE keyword. All security specifications must 
satisfy the requirements of the remote system. 


The format of the SECURITY keyword is: 
SECURITY(n reserved-word|'literal'|field-name-1 
|&field-name-1[.3.]) 


The n parameter required by the remote system identifies the 
security subfield being described. The n parameter can be 
specified as: 


¢ 1 for a profile ID 
e 2 for a password 
¢ 3 for a user ID 
You can specify the following values for the security fields: 


reserved-word. This value can be specified as one of 
the following: 
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e *USER. Specifies that the user’s profile name on 
the local AS/400 system is used as the security 
field. 


e *NONE. Specifies that the security field is not sup- 
plied. 


‘literal’. A literal value of up to 10 characters that con- 
tains the needed security information. 


field-name (or &field-name). The name of a field in the 
record format that contains the needed security informa- 
tion. If you want to send blanks as the security field, 
you must specify this as a literal value or use a field 
name. 


If you do not explicitly define the security values on the 
SECURITY keyword for an evoke request, no security values 
are sent. 


Refer to Chapter 8 for information about remote program 
start considerations on the AS/400 system. 


SYNLVL Keyword: Use the SYNLVL DDS keyword to 
specify the level of synchronization supported on this trans- 
action. It determines whether the programs support no syn- 
chronization, confirmation-level synchronization (using 
CONFIRM and RSPCONFIRM keywords), or commit-level 
synchronization. Commit-level synchronization is a two- 
phase commit protocol using the PRPCMT keyword and 
commit and rollback operations. The SYNLVL keyword is 
valid only in conjunction with the EVOKE keyword. 


The format of the SYNLVL keyword is: 
SYNLVL[ («NONE | *CONFIRM|*COMMIT) ] 


You can specify the following optional values for the SYNLVL 
keyword: 


*“NONE. Specifies that confirmation of the receipt of 
data is not allowed on this transaction. For example, on 
the AS/400 system the CONFIRM keyword is not 
allowed with SYNLVL (*NONE). 


*“CONFIRM. Specifies that the sending program can 
request that the receiving program responds to receipt of 
the data. The receiving program can send a positive 
response, or the receiving program or system can send 
a negative response. For example, on the AS/400 
system the CONFIRM keyword is allowed on write oper- 
ations. 


Refer to the keyword descriptions for “Confirm 
(CONFIRM)” on page 6-4, “Receive-Confirm” on 

page 6-19, and “Respond-to-Confirm (RSPCONFIRM)” 
on page 6-12 for additional information on CONFIRM 
processing. 


*COMMIT. Allows the programs to operate as described 
for the *CONFIRM value. Moreover, *COMMIT requires 
programs to use two-phase commit processing to protect 
their resources. Two-phase commit processing allows 
programs to synchronize updates to protected resources 
(such as databases). If necessary, updates can be 


rolled back, so that the resources remain synchronized. 
Refer to the descriptions of the PRPCMT, RCVROLLB, 
and RCVTKCMT keywords for more information on two- 
phase commit processing. The Backup and Recovery 
book has information about commitment control and the 
commit and rollback operations, which are an essential 
part of two-phase commit processing. 


Evoke Illustration: Figure 6-1 shows how to start a 
target program on the remote system. 


E¥ The source program issues an evoke request to start 
the program at the remote system. 


AS/400 System 


Es The evoke parameters, including program name, library 
name, and security information are sent to the remote 
system. Program initialization parameters can also be 
sent with the program start request (optional). 


A successful completion return code tells the source 
program that the evoke request was accepted and a 
program start request was sent to the remote system. 
If the program start request is successful, both the 
program at the remote system and the communications 
transaction are started. 


ICF 
Source Data Communications 
Program Management Support 
e 
e Program Start 
e Request to 
Write with Remote System 
ss erp i edeses fF 
1 | Evoke | 
2 > WILL > : 
7 Data Link 
Return Code Za 
—Ez———— Eee 


Answer from 
Remote System 


Figure 6-1. Starting a Target Program 


Differences between DDS and 
System-Supplied Evoke Functions 


The DDS EVOKE keyword is handled differently from the 
system-supplied evoke formats when data is also sent. The 
data passed on a system-supplied evoke format is treated as 
a parameter and is passed along with the program start 
request to the remote system. Any data passed using the 
EVOKE keyword, except for user-defined parameters, 
program names, and library names, is not treated as a 
parameter. This information is sent separately from the 
program start request after the evoke request completes suc- 
cessfully. Therefore, the remote program must issue a read 
operation to receive the data when the DDS EVOKE keyword 
is used. 
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Sending Data 


You may begin sending and receiving data when both 
systems are communicating with each other. This section 
discusses sending data. See “Receiving Data” on page 6-7 
for a discussion on receiving data. 


You can use several DDS keywords and combinations of 
keywords in conjunction with sending data. These keywords 
provide additional information about how to process the data 
being sent to the remote program. 


The following are valid functions that can be done when 
sending data. The DDS keywords associated with these 
functions are valid only with output operations. 
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Variable-Length Data (VARLEN) 


The length of an output operation is determined by the 
record format specified. The record format length is deter- 
mined by the record definition in DDS. You can use the 
VARLEN keyword to change the length of the data record 
sent with each write operation, while using the same record 
format. 


The format of the VARLEN keyword is: 
VARLEN(&field-name) 


The field-name parameter specifies the length of the record 
sent on a write operation. The length cannot be greater than 
the length of the data field defined for this record format. 
The length you specify with the VARLEN keyword overrides 
any length specified elsewhere in your write operation. 


Variable-Buffer-Management 
(VARBUFMGT) 


Use the VARBUFMGT keyword to send or receive multiple or 
partial records, rather than just one record, with one record 
format per write or read operation. 


Using the VARBUFMGT keyword allows you to specify the 
length of data independently of the data itself. A program 
uses the data length specified as the value passed in the 
variable length (VARLEN) DDS keyword, or if VARLEN is not 
used, the length of the record format specified on the read or 
write operation. The length specified must be greater than 
zero. 


This function is valid only for APPC. Refer to the APPC Pro- 
gramming book for more information. 


Force-Data (FRCDTA) 


Use the FRCDTA keyword on a write request to cause the 
communications support to immediately send any data cur- 
rently held in the output buffer. The communications support 
does not wait for the buffer to fill. Any data specified on the 
same operation as the force-data request is also sent. No 
operation is done if there is no data in the buffer to send. 


Note: This causes the data to be sent to the other system, 
but not necessarily to the remote program. 


Confirm (CONFIRM) 


Use the CONFIRM keyword to request that the remote 
program respond when it has received the data you sent. An 
output operation with the CONFIRM keyword specified forces 
any data in the output buffer to be sent. The CONFIRM 
keyword also asks the remote program to respond when the 
data is received. The operation does not complete, and your 
program does not continue, until a response is received. 

The remote program must respond with either a positive or 
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negative reply as to whether the data was successfully 
received. 


Note: Refer to the RCVCONFIRM keyword described in 
“Using Response Indicator Keywords” on page 6-18 and the 
RSPCONFIRM keyword described in “Additional Keywords” 
on page 6-12 for information on how to receive and respond 
to a confirm request. 


If a positive response is received, the output operation com- 
pletes normally. If a negative response is received, the 
major/minor return code and ICF message indicate the 
reason. 


CONFIR\M is valid only on a transaction with a synchroniza- 
tion level of confirm. 


Format-Name (FMTNAME) 


Use the FMTNAME keyword to pass the name of the record 
format used for this output operation to the remote system. 
If the remote system is an AS/400 system, ICF uses this 
name to find the record format to use when receiving the 
data at the remote system. 


Note: If you use the FMTNAME keyword while sending data 
to another AS/400 system, you should specify *RMTFMT for 
the format selection (FMTSLT) parameter on the Add Inter- 
system Communications Function Device Entry 
(ADDICFDEVE), Change Intersystem Communications Func- 
tion Device Entry (CHGICFDEVE), or Override Intersystem 
Communications Function Device Entry (OVRICFDEVE) 
command at the system at which the data is received. 


Subdevice-Selection (SUBDEV) 


Use the SUBDEV keyword to specify the remote system 
device (such as a printer or diskette) to which you are 
sending data. The receiving controller then directs output 
from your program to the appropriate device. The subdevice 
selection is designed primarily to support specific hardware 
devices, such as 3776, 3777, and 3780. 


The format of the SUBDEV keyword is: 
SUBDEV (type) 


The type parameter values, *DC1, *DC2, *DC3, and *DC4, 
are required to specify the device control character used by 
the receiving controller so that output can be directed to the 
appropriate device. 


End-of-Group (ENDGRP) 


Use the ENDGRP keyword to indicate to the remote system 
the end of a user-defined group of records. The communica- 
tions type you are using determines the type of indication 
sent to the remote system to indicate the end of a group of 
records. 


Note: Refer to the RCVENDGRP keyword described in 
“Using Response Indicator Keywords” on page 6-18 for infor- 
mation on how to handle receiving an end-of-group indi- 
cation. 


Function-Management-Header (FMH) 


Use the function-management-header (FMH) keyword to 
send control information about the data that follows to the 
remote system. A function-management-header is valid only 
with the first record of a group. 


Note: Refer to the RCVFMH keyword described in “Using 
Response Indicator Keywords” on page 6-18 for information 
on how to handle receiving a function-management-header. 


Control-Data (CTLDTA) 


Use the CTLDTA keyword to send control data to the remote 
program. Control data has meaning only to the partner 
transaction programs. For example, this data can be used 
as prefix control information for application data that follows 
it, or it can be used to carry special data for mapped conver- 
sation transactions. 


This keyword is valid only for APPC. See the APPC Pro- 
gramming book for more information. 


Prepare-for-Commit Function 


Your program uses the prepare-for-commit (PRPCMT) 
function to request one of its partners to prepare to commit 
its protected resources. The partner can respond with a 
commit, a rollback, or a FAIL operation. If the partner 
responds with a FAIL operation, the partner program is in 
control and can attempt to correct any errors that it detected. 


The PRPCMT function contrasts with the commit operation in 
the following ways: 


e¢ PRPCMT only works with one conversation at a time. 
The commit operation attempts to commit all protected 
resources in the two-phase commit transaction. 


e¢ PRPCMT only prepares the remote protected resources 
to be committed. In other words, the remote resources 
have been locked and cannot be changed. They are in 
a state in which they can either be committed or rolled 
backed. Eventually, the remote resources are com- 
mitted or rolled back depending on whether the rest of 
the two-phase commit transaction commits or rolls back 
its protected resources. 


The commit operation ends only after all remote pro- 
tected resources in the two-phase commit transaction. 
have either been committed or rolled back. 


e¢ PRPCMT allows the application program to attempt error 
recovery without rolling back the protected logical unit of 
work (LUW). When the application program issues a 
PRPCMT and the partner responds with a fail function, 
the PRPCMT function completes. The application 
program can then attempt error recovery, and issue the 
PRPCMT function again. 


Note: The remote program is in send state after 
responding with the fail function. The local application 
program cannot issue the PRPCMT function again until 
the conversation states change. 


When the application program issues a commit operation 
and the partner responds with a fail function, the logical 
unit of work is rolled back. 


An operation that includes the prepare-for-commit function 
does not complete until the remote program responds with a 
commit or rollback operation or a FAIL or EOS function. 


After the PRPCMT function completes successfully, your 
program can do any one of the following. 


e Use the commit operation to commit protected 
resources. 


e Use the rollback operation to roll back the protected 
logical unit of work (LUW). 


e Use the end-of-session function to end the attachment of 
the program to a session and roll back the protected 
LUW. 


Note: The prepare-for-commit function only applies when 
SYNLVL(*COMMIT) is specified in the EVOKE DDS record 
format used by the source program, or when the program 
start request received by a target program establishes a syn- 
chronization level of commit. An AS/400 target program can 
determine the synchronization level established by the 
source program by using the get-attributes operation. 


The prepare-for-commit function causes any data currently 
held in the buffer to be sent, including any data on a write 
operation that specified the prepare-for-commit function. 


Transaction-Synchronization-Level 
Function 


Your program uses the transaction-synchronization-level 
(TNSSYNLVL) function to specify that synchronization for this 
transaction should be done at the level that the SYNLVL 
keyword specified on the evoke. 


The TNSSYNLVL keyword can only be used if specified with 
one of the following keywords. 


¢ ALWWRT 
« DETACH 
e INVITE 
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Figure 6-2. Using the CONFIRM, FRCDTA, and FMTNAME Keywords to Send Data 


Examples of Sending Data 


Figure 6-2 shows how to use the CONFIRM, FRCDTA, and 
FMTNAME keywords when sending data. 
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Your program issues a write-with-confirm operation to 
send data to the remote system and asks the remote 
system for a response. 


Your program cannot continue processing until a 
response is received from the remote system. Your 
program checks the return code to determine if the 


remote system issued a positive or negative response. 
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If a successful return code is received, your program 
continues sending several records. On the last record, 
your program also specifies the force-data function. 
The FRCDTA causes all buffered data to be sent. The 
return code indicates the data is successfully sent. 
The force-data request does not wait for a response 
from the remote system. 


Your program sends a record. The format-name func- 
tion indicates that the record format name used on this 
write is also sent to the remote system. The remote 
system uses this record format when receiving the 
data. 


Figure 6-3 on page 6-7 shows how to use the ENDGRP and 
FMH keywords when sending data. 
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Figure 6-3. Using the ENDGRP and FMH Keywords to Send Data 


F¥ = Your program sends a record to the remote system 
and, with the FMH keyword, indicates that the first part 
of the data is function-management-header data, which 
contains information about the user data that follows. 


EZ sYour program continues sending data records to the 
remote system. Your program uses the end-of-group 
function on the last record to indicate it is the last in 
this group of records. 


Receiving Data 


You can use two operations to receive data: read and read- 
from-invited-program-devices. In addition, you can use the 
invite, timer, and record-identification functions with the pre- 
ceding operations to provide additional functions when 
receiving data. 


The read operation receives data from the program device 
you specify. This operation differs from the read-from- 
invited-program-devices operation, which receives data from 
any program device with a previously issued invite request. 
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Invite (INVITE) 


The INVITE keyword prepares your program to receive data. 
You must do an output operation with the INVITE keyword 
specified to issue an invite function. You can combine addi- 
tional output keywords or data with the invite function. Your 
program can continue processing after issuing the invite 
request, and does not need to wait for the data. 


The read-from invited-program-devices operation is a com- 
panion to the invite function. After issuing an invite function, 
you use the read-from-invited-program-devices operation to 
receive the data from the remote system. 


You do not need to issue an invite function before a read 
operation to receive data. However, if an invite is out- 
standing for a program device to which a read is issued, the 
read completes the invite and receives the data. 


Note: When a program device is invited, it is recommended 
that a read-from-invited-program-devices operation be per- 
formed rather than a read operation to receive data. Perfor- 
mance may be degraded if your program issues multiple 
read operations to invited program devices. 


Refer to Chapter 5 for additional information about the read 
and read-from-invited-program-devices operations and their 
relationship to the invite function. 
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Invite with Transaction Synchronization Level: 
When your application program specifies the TNSSYNLVL 
keyword with the invite function, the additional function per- 
formed depends on the synchronization level of the conver- 
sation. The TNSSYNLVL keyword can be specified with the 
invite function only if the synchronization level is *NONE or 
*CONFIRM. Figure 6-4 on page 6-8 shows the details. 


Figure 6-4. TNSSYNLVL Function with Invite 


Synchronization Function 

Level 

*NONE The force-data function is performed in addi- 
tion to the invite function. 

*CONFIRM The confirm function is performed in addition 
to the invite function. 

*COMMIT Not allowed 


Timer (TIMER) 


Your program can use the timer function before performing 
some specified function, such as a read-from-invited- 
program-devices operation. The timer function specifies an 
interval of time (in hours, minutes, and seconds) to wait 
before your program receives a timer-expired (0310) return 
code. 


Use the TIMER keyword to set the timer for the specified 
interval of time. The TIMER keyword is issued on an output 
operation. 


The format of the TIMER keyword is: 
TIMER(HHMMSS | &field-name) 


The parameter specified with the TIMER keyword can be one 
of the following: 


HHMMSS 
A literal value where HH is the number of hours, 
MM is minutes, and SS is seconds. 


&field-name 
A value where the field contains the TIMER value in 
the same HHMMSS format. 


Your program continues to run, and all operations and func- 
tions are valid during the time interval. Your program must 
issue a read-from-invited-program-devices operation some 
time after it has issued the timer function, so it can accept 
the return code indicating that the timer interval has ended. 


Only one time interval can be maintained for your program. 
If a previous timer function has been issued and the timer 
has not yet ended, the old time interval is replaced by the 
new interval. 


The timer function can be used to vary the maximum amount 
of time that a read-from-invited-program-devices operation 
will wait for a response. When the time interval set by the 
TIMER keyword is in effect, the value specified for the 
WAITRCD parameter on the CRTICFF command is ignored. 
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There is a minor difference between the functions of the 
TIMER keyword and the WAITRCD parameter. When a 
write operation is done using the TIMER keyword, the timer 
starts immediately. The time interval is no longer in effect 
when a subsequent read-from-invited-program-devices oper- 
ation completes or when the end of the interval is reached. 
When the WAITRCD parameter is used, the timer starts 
when a read-from-invited-program-devices operation is per- 
formed. 


You can use the timer function to retry other operations that 
may not be successful, possibly because of a temporary lack 
of resources (for example, during an acquire operation). To 
do this, issue the timer function, and then perform read-from- 
invited-program-devices operations until the timer interval 
ends. (The read-from-invited-program-devices operation 
allows the program to continue receiving input from other 
invited program devices while waiting for the timer.) 


Refer to Chapter 5 for additional information on the read- 
from-invited-program-devices operation and its relationship to 
the timer function. 


Record-ldentification (RECID) 


The RECID keyword identifies and selects the record format 
to use with an input operation based on the data received 
from the remote program. This keyword is applicable only if 
you specify FMTSLT(*RECID) on the ADDICFDEVE or 
OVRICFDEVE command. 


The format of the RECID keyword is: 
RECID(starting-position compare-value) 


Specify the starting-position parameter as either nnnnn or 
*POSnnnnn, where nnnnn defines the beginning position of 
the compare value within the record format. The first posi- 
tion in the record is position 1. Specify the compare-value 
parameter as: 


*ZERO. The data character in the position specified 
must be 0 (hex FO) to match the record identifier. 


“BLANK. The data character in the position specified 
must be a blank (hex 40) to match the record identifier. 


‘literal’. The data received, beginning with the position 
defined by the starting-position value, must match the 
literal specified here. 


If the length of the record received is less than the number of 
positions examined for RECID value, the positions past the 
end of the record are treated as if they contained blanks. If 
the RECID keyword compare value specifies blanks for those 
positions, the data is considered a match. 


For example, if your program receives both header and detail 
records from the remote program, you can specify the fol- 
lowing in your ICF file: 


RECID(1 'H’) 
RECID(1 'D’) 


Your program issues input operations to the file without spec- 
ifying a record format name. You do not specify a record 
format name because the correct record format is not known 
until the data is received. Your program receives the records 
(either headers or detail) in the order they are sent by the 
remote program. For this example, the sending and 
receiving programs provide for an explicit code (an H for 
header records and a D for detail records) to identify the type 
of record being sent and received. The RECID keyword 
identifies the input buffer location where the H or D appears, 
and specifies the value (starting in the position specified) that 
identifies the record type. 


The remote program must identify the type of record (either 
header or detail) by placing H or D in the first position of the 
data buffer. 


For each input operation, the value specified in the first posi- 
tion of the buffer is compared with the value specified on the 
RECID keyword. If the value in a record is H, the format 
associated with the RECID(1 'H') specification is selected. 
Duplicate RECID keyword compare values are not checked. 
The first format with a compare value that matches the 
received value is used. 


Be careful how you specify more than one RECID keyword 
within a file if more than one compare value begins in the 
same record position. For example, the following compare 
values begin in the same position: 


RECID(1 'A’) 
RECID(1 'AB') 
RECID(1 'ABC’) 


The first format is always selected if the data starts with an 
A, because any received records matching the last two 
compare values also match the first. Specify the longest 
value first to prevent confusion. 


RECID(1 'ABC’) 
RECID(1 'AB’) 
RECID(1 ‘A’) 


You can use the RECID DDS keyword to eliminate pro- 
cessing of alphanumeric data in fields that should contain 
only numeric data. Refer to “Input Considerations” on 
page 8-3 for more information on eliminating data decimal 
errors. 


Problem Notification 


Use the fail, cancel, and negative-response functions to 
inform the application program of an error that has occurred 
in the data being sent or received. The DDS keywords asso- 
ciated with these functions are specified on an output opera- 
tion. 


Fail (FAIL) 


Use the FAIL keyword to indicate that an error has occurred 
when sending and receiving data. 


If a program that is sending data issues a fail, it may indicate 
that the data just sent was in error. Your program can con- 
tinue to send data and is usually responsible for the first 
error recovery. The communications type you are using 
determines whether data that is in the output buffer before 
issuing the fail function is sent to the remote system with the 
fail indication. The communications type determines the type 
of notification sent. 


You can also use a fail function if your program receives 
data and detects an error in the received data. Figure 6-5 
on page 6-10 shows how to use the fail function when your 
program is receiving data and detects an error. 
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Figure 6-5. Using the FAIL Keyword to Send an Error Indication 
E¥ = Your program is receiving data from the remote PRPCMT, the application program can try to correct 


program. the problem. 


Es While receiving data, your program determines that it 


Bes ne na Refer to the RCVFAIL keyword described in “Using 
must send a fail indication to the other program. 


Response Indicator Keywords” on page 6-18 for information 
A message or data is then sent (write operation) to tell on handling receipt of a fail indication. 
the other program why you sent the fail indication. 


When a fail function is the response to a commit oper- Cancel (CANCEL) 
ation, the system rolls back the protected LUW on the 


side that issued the commit operation. The side that Use the CANCEL keyword to tell the remote system to 
issued the fail function must do a rollback operation cancel the group of records you are currently sending. Your 
after the request to roll back is received from the program can use the cancel function only when sending data 
partner. When a fail function is the response to a (similar to issuing a fail when your program is sending data). 
PRPCMT function, APPC does not roll back the pro- Figure 6-6 on page 6-11 shows how to use the cancel func- 
tected LUW. Since APPC does not do a rollback for tion when a program is sending data and detects an error. 
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Figure 6-6. Using the CANCEL Keyword to Send an Error Indication 


E¥ = Your program is sending data to the remote system. 


Your program checks the data and determines that 
something is wrong with it. 


2 | 

Your program uses a cancel function to tell the remote 
system to discard the data you have sent. 

4 | 


Your program can send a message indicating the 
problem, send the data again, receive more data, or 
end the transaction. 


Refer to the RCVCANCEL keyword described in “Using 
Response Indicator Keywords” on page 6-18 for information 
on handling receipt of a cancel indication. 


Negative-Response (NEGRSP) 


Use the NEGRSP keyword to tell the remote system that the 
data just received is not correct. The format of the NEGRSP 
keyword is: 


NEGRSP[ (&field-name) ] 
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The optional parameter on the NEGRSP keyword specifies 
the name of the field that contains sense data to be sent to 
the remote program with the negative response. 


Issuing a negative-response function is similar to issuing a 
fail function while receiving data, except that you can also 
include 8 characters of sense data with the negative- 
response function. The sense data tells the remote system 
what is wrong with the data you received. The first 4 charac- 
ters of the sense data must begin with 10XX, 08XX, or 0000. 
The last 4 characters are user-defined. Refer to the appro- 
priate communications programming book for the commu- 
nications type you are using for more information about the 
allowed sense values. 


The sense data is sent in the normal output buffer. No other 
data is allowed to be sent with a negative-response function. 


Figure 6-7 on page 6-12 shows how to send a negative 
response with a sense code to the remote system. 
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Figure 6-7. Sending a Negative Response with Sense Code to Remote System 


F¥ = Your program finds that the data it is receiving is not 
correct. 


Es The program sends a negative response to the remote 
system, including the sense data 08110000. The neg- 
ative response tells the remote system that the data 
received is wrong, and the sense data 08110000 asks 
the remote system to cancel the current group of data 
records. 


Refer to the RCVNEGRSP keyword described in “Using 
Response Indicator Keywords” on page 6-18 for information 
on handling receipt of a negative response indication. 


Additional Keywords 
You can use the respond-to-confirm, request-to-write, allow- 


write, and cancel-invite functions to perform additional func- 
tions. 
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Respond-to-Confirm (RSPCONFIRM) 


Use the RSPCONFIRM keyword to send a positive response 
to a received confirm request. The respond-to-confirm func- 
tion can be used only when a confirm request is outstanding. 
You can check the major/minor return codes or use the 
RCVCONFIRM indicator to determine when to issue a 
respond-to-confirm function. After sending the response, 
your program can continue processing as indicated by any 
other information received. 


Figure 6-8 on page 6-13 shows how to use the respond-to- 
confirm function. 


AS/400 System 


ICF 
Source Data 


Program Management 


1 | Read 


Return Code 


Communications 


Support 


Eo WWW... __ YHHfypvg4h; <Q Dstt a | Received 


with Confirm 


Request 


2 | Write vith p> = > -------- - —-—-—- +-----® Positive Response 


RSPCONFIRM 


Data 


3 | Read 


Sent 


-. £2 


<< atta Is Received 


Figure 6-8. Using the Respond-to-Confirm Function 


F¥ = Your program is receiving data from the remote 
system. The return code indicates data and a confirm 
request. The read could have also been done with the 
RCVCONFIRM keyword to indicate that a confirm 
request was received. 


1 sYour program issues a write operation with the 
RSPCONFIRM keyword in effect to acknowledge the 
receipt of data. 


Your program continues to receive because the remote 
program is still in send state. 


RSLS679-2 


Request-to-Write (RQSWRT) 


Use the RQSWRT keyword, while your program is receiving 
data, to ask the remote system to stop sending so your 
program can send. The request-to-write function tells the 
remote system you want to change the direction of data 
transmission. If the remote system allows the change, your 
program can send either data or a message, or both, to the 
remote system. After issuing the request-to-write, your 
program must continue receiving data until the remote 
system sends a notification indicating it is ready to receive. 


Figure 6-9 on page 6-14 shows how to use the request-to- 
write function. 
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Figure 6-9. Using the Request-to-Write Function 


6-14 


Your program is receiving data from the remote 
system. The program processes the data received, 
then receives data again. 


At some time while data is being received, your 
program determines that it needs to send a message 
to the remote system. Your program issues a write 
operation, with the RQSWRT and INVITE keywords in 
effect, to ask the remote system to stop sending so 
your program can send the message. The request- 
write indication is sent to the remote system at the first 
available opportunity. Since the session is in receive 
state, the indication may be held until the next data 
record is received. 


After issuing the request-to-write function, your 
program must continue receiving data until it gets a 
return code indicating that the remote system is ready 
to receive. To continue receiving, another read-from- 
invited-program-devices operation is used. 
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Another invite and read-from-invited-program-devices 
operation is issued to continue receiving data. 


When the remote system is ready to receive, it sends 
one more data record with a change-direction indi- 
cation. The record says the remote system is now 
ready to receive data or, as in this example, a 
message. 


A write operation with the INVITE keyword in effect is 
used to send the message to the remote system and 
ask the remote system to continue sending data. 


When your program receives a request-to-write request from 
the remote system, a code is set in the I/O feedback file- 
dependent section. Refer to Figure C-5 on page C-3 for 
more information about where this field is in the I/O feedback 


area. 


The code indicates the following conditions: 


0 Continue sending as normal. 


1 A request-to-write has been received. 


Refer to the appropriate communications programming book 
for the communications type you are using for more specific 
information on what this code means for the communications 
type you are using. 


Allow-Write (ALWWRT) 


Use the ALWWRT keyword to explicitly inform the remote 
system that your program is done sending. The allow-write 
function clears the buffers, forcing any data to be sent. The 
same function occurs automatically if you issue an input 
operation after a write operation. In that case, the ALWWRT 


Your application program uses the allow-write (ALWWRT) 
function to inform the remote program that your program is 
done sending data and is ready to receive. This causes a 
change-direction indicator to be sent to the remote program. 


After issuing the allow-write function, your program can then 
issue an input operation to receive data from the remote 
program. 


When your application program specifies the TNSSYNLVL 
keyword with the ALWWRT keyword, the additional function 
performed depends on the synchronization level of the con- 
versation. Figure 6-10 shows the details. 


Figure 6-10. TNSSYNLVL Function with ALWWRT 


DDS keyword is not required. After issuing an allow-write, Synchronization Function 
your application program can issue an input operation to Level 
receive data from the remote system. *NONE The force-data function is performed in addi- 
: : : tion to the allow-write function. 
Figure 6-11 shows how to use the allow-write function. : fas ; oF 
*CONFIRM The confirm function is performed in addition 
EF¥ = Your program sends several data records to the to the allow-write function. 
remote system. *COMMIT The conversation enters defer receive state 
EYou use an allow-write with the last record to inform until your application program issues a 
the remote system you are done sending. commit operation, a force-data function, ora 
confirm function. Once the commit operation, 
The remote system can now send data, and your force-data function, or confirm function com- 
program must begin receiving. pletes successfully, the conversation is in 
receive state. 
Refer to “Receive-Turnaround” on page 6-19 for information 
on handling receipt of an allow-write indication. 
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Figure 6-11. Using the Allow-Write Function 
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Figure 6-12. Using the Cancel-Invite Function 


Cancel-Invite (CNLINVITE) 


Use the CNLINVITE keyword to cancel a valid invite for 
which no data has yet been received from an invited program 
device. Your program can continue to send data. 


Figure 6-12 shows how to use the CNLINVITE keyword. 


E¥ = Your program issues an invite operation to receive data 
from the remote program, then continues processing. 


EZ sYour program uses the cancel-invite function to cancel 
the previous invite operation. Your program must 
check the return code it receives to determine if any 
data has already been received from the remote 
system. 


Your program can continue to send data if data was 
not received. 
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Ending a Communications Transaction 


A communications transaction can be ended by your 
program or by the program at the remote system. Your job 
and the remote system that your system is communicating 
with determine the program that ends the transaction. 


Communications with the remote program end when your 
program ends the transaction. However, the session may 
still exist if your program started the session. If the session 
still exists, you can end the session or you may be able to 
start another program at the remote system. 


Detach (DETACH) 

Use the DETACH DDS keyword to end the transaction. The 
detach explicitly informs the remote program that your 
program is done sending and has ended the transaction. 


Figure 6-13 on page 6-17 shows how your program can end 
a communications transaction. 
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Figure 6-13. Ending a Communications Transaction 


F¥ Your program issues the detach to tell the remote 
system that your program ended the communications 
transaction. 


Refer to the RCVDETACH keyword described in “Using 
Response Indicator Keywords” on page 6-18 for information 
on handling receipt of a detach indication. 


If a detach function is issued by the target program, the EOS 
function is issued after the detach function is completed. 


This should be done since neither the EOS, Detach, or any 
other ICF function can end the session (that is, cause an 
UNBIND to be sent). 


Using the Detach Function When the 
Synchronization Level is None 


When the synchronization level is none and the detach and 
transaction-synchronization-level functions are used together, 
force-data and detach functions are performed. 


After a detach function is accepted by your program, no 
further input or output operations with the remote program 
are allowed. 


Using the Detach Function When the 
Synchronization Level is Confirm 


When a detach function and a confirm function or 
transaction-synchronization-level function are used together, 
a confirm function is performed. If the remote program 
responds positively, the detach function is performed. If the 
remote program responds negatively, or has already sent a 
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negative response, the transaction may not end immediately. 
The sender of the negative response is responsible for the 
initial error recovery. The point at which action is taken to 
recover from the error determines when the transaction is 
ended. 


To respond positively to the detach function with a confirm or 
transaction-synchronization-level function, the remote 
program must use the respond-to-confirm function. 


To respond negatively to the detach function with a confirm 
or transaction-synchronization-level function, the remote 
program should use the fail function. 


After a detach function is accepted by your program, no 
further input or output operations with the remote program 
are allowed. 


Using the Detach Function When the 
Synchronization Level is Commit 


For two-phase commit processing, the detach function must 
be accompanied by the transaction-synchronization-level 
function. The transaction does not end until your program 
issues a commit operation, and the commit operation com- 
pletes successfully. If the commit operation fails, the fol- 
lowing is done. 


e The logical unit of work is rolled back. 

e The transaction is not ended. 

e The conversation state is returned to what it was at the 
last commit boundary. 
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Using the Detach Function From a Target 
Program 


After a target program issues a detach function, both the 
session and the transaction end. No further operations are 
valid on the program device. 


Ending the Communications Session 


How the communications session is ended depends on 
whether your program or the remote system started the 
session. 


The release operation ends the session only if all processing 
is complete. The end-of-session operation always ends the 
session. 
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End-of-Session (EOS) 


Use the EOS DDS keyword to issue an end-of-session func- 
tion. The only possible return codes from end-of-session are 
0000 or 830B (program device not acquired). 


If the target program ends the transaction by the detach 
function, the session is ended implicitly. If the source 
program ends the transaction, the target program must issue 
an end-of-session or go to the end of the job to end the 
session. Figure 6-14 shows how you can end the session 
using the release operation and the end-of-session function. 


For conversations started using EVOKE with SYNLVL(*COMMIT) 
specified: 


e If EOS is issued after a TAKE_COMMIT_» indication has 
been received by the transaction program (TP), resyn- 
chronization processing is performed. 

e In all other cases, the EOS causes the logical unit of 
work (LUW) to be put into rollback required state. The 
TP must perform a rollback operation before working 
with any other resources involved in that LUW. 
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Figure 6-14, Using the Release and End-of-Session Functions 


F¥ = Your program issues the release operation to end the 
current communications session. 


Zs The return code tells your program whether the session 
was ended, or if an error occurred while trying to end 
the session. If, for example, all transactions have not 
ended when the release operation is issued, an error 
occurs and the session is not ended. 


If an error occurs and normal recovery is not possible, 
your program can use the end-of-session function to 
end the session. 


EJs The end-of-session function always ends the session. 
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Using Response Indicator Keywords 


Response keywords provide information to your program 
about the data record being received or the actions taken by 
the remote program. Check which response indicators are 
set when your program does an input operation to determine: 


e What the remote program sent 

e What the remote program expects from your program 

e What your program’s next operation should be 
Response keywords are only effective for input operations or 
a combined output then input. They have no effect on an 


output operation. Multiple response keywords can be used 
on a single input operation. 


Receive-Confirm 

Use the RCVCONFIRM keyword to request that a response 
indicator be set on if the record received from the remote 
system contains a confirm request. A received confirm 
request indicates that the remote program expects your 
program to do a specific action to synchronize the programs. 
The action can be a write with the RSPCONFIRM keyword 
(positive response), or a write with the FAIL keyword (nega- 
tive response). If the session is abnormally ended (end-of- 
session or job end before ending the transaction), a negative 
response is sent. 


This same type of information can be determined by 
checking the major/minor return code returned in the I/O 
feedback area at the completion of each operation. 


The program receiving the confirm indication is responsible 
for making sure that the response (positive or negative) is 
returned to the program requesting the confirmation. 


If you want to return a positive response to the remote 
system, issue a write with the RSPCONFIRM DDS keyword 
in effect. If you want a negative response returned, either 
issue a write with the FAIL DDS keyword in effect, or abnor- 
mally end the session (end-of-session or job end before 
ending the transaction). 


Receive-Control-Data 


Use the RCVCTLDTA keyword to request that a response 
indicator be set on if the record received from the remote 
system contains a control-data indication. The response indi- 
cator is set if the data received in the input buffer is control 
data. 


Receive-End-of-Group 


Use the RCVENDGRP keyword to request that a response 
indicator be set on if the record received from the remote 
system contains an end-of-group indicator. The response 
indicator is set if the last record received in the input buffer 
was the end of a user-defined group of records. 


Receive-Function-Management Header 


Use the RCVFMH keyword to request that a response indi- 
cator be set on if the record received from the remote system 
contains a function-management-header indication. The 
response indicator is set if the data received in the input 
buffer is function-management-header data. Asynchronous, 
finance, intrasystem, and retail communications give the user 
data along with the function-management-header indication 
in one operation. If you are using SNUF, however, you must 
do an additional input operation to get the remaining user 
data that accompanied the function-management-header. 


Receive-Fail 


Use the RCVFAIL keyword to request that a response indi- 
cator be set on if the record received from the remote system 
contains a fail indication. The remote program informs your 
program that it found something wrong while sending or 
receiving data. Your program should issue an input opera- 
tion after receiving a fail indication. The program sending the 
fail indication must start the error recovery. 


Receive-Cancel 


Use the RCVCANCEL keyword to request that a response 
indicator be set on if the record received from the remote 
system contains a cancel indication. The remote system 
informs your program that the current chain of data is not 
correct. Your program should discard the data, then con- 
tinue to receive or end the job. 


Receive-Negative-Response 


Use the RCVNEGRSP keyword to request that a response 
indicator be set on if the data received from the remote 
system contains a negative-response indication. The remote 
system informs your program that an error was detected in 
the data it just received. You may receive an 8-byte sense 
code with the negative response signal. 


Receive- Turnaround 


Use the RCVTRNRND keyword to request that a response 
indicator be set on if the data received from the remote 
system contains a change-in-transmission-direction indi- 
cation. The remote system informs your program that it is 
finished sending data, and is ready to receive data. Your 
program can begin sending data. 


Receive-Detach 


Use the RCVDETACH keyword to request that a response 
indicator be set on if the record received from the remote 
system contains a detach indication. The remote system 
informs your program that it is ending this communications 
transaction with your program. Your program can no longer 
communicate with the remote program. The session with the 
remote system may still exist if your program started the 
session. lf the remote system started the session, commu- 
nications with the remote system are ended. 


Receive-Rollback 


Use the RCVROLLB keyword to request that a response 
indicator be set on as an indication of one of the following 
conditions: 


e The remote program sent a ROLLBACK. This indicates 
that the remote program expects your program to 
rollback its protected resources. 
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¢ The protected LUW entered the rollback required state. 


Your program must respond with a rollback operation. Your 
program can only get this response indicator if it has a con- 
versation with a synchronization level of commit. 


This response indicator can be received with the following 
return codes. 


¢ 0054 

¢ 0254 

¢ 80F9, 80FA, 80FB 

¢ 81F0, 81F1, 81F2, 81F3, 81F4, 81F5 
¢ 83FB, 83FC, 83FD, 83FE, 83FF 


Receive-Take-Commit 


Use the RCVTKCMT keyword to request that a response 
indicator be set on as an indication that the remote program 
sent a PRPCMT function or a commit operation. This indi- 
cates that the remote program expects your program to 
determine if it can commit its protected resources. Your 
program must either do a commit or rollback operation or a 
FAIL or EOS function. Your program can only get this 
response indicator if it has a conversation with a synchroni- 
zation level of commit. 


This response indicator can be received with major return 
codes 02 (end job or end subsystem in progress) or 03 (no 
data received). The major return code can be accompanied 
by a minor return code of 57, 58, or 59. 


6-20 —ICF Programming V4R1 


Example DDS Files for Creating an 
Intersystem Communications Function File 


Figure 6-15 and Figure 6-16 on page 6-21 are DDS source 
files that can be used to create an ICF file. Files created 
using this source DDS are used in the application program 
examples in Chapter 9 through Chapter 11. 


[REGEDIT IO SII EIT O OITA IOC ITO I IOI TOI III I III IIA IH 


Ax * 
Ax ICF FILE * 
Ax USED IN BATCH DATA TRANSFER PROGRAM * 
Ax * 
DR KKK KI KIKI KIKI KKK IKK KI KKK IKK KI KK KI KK KIKI KKK KKK IK KIRKE I IK 
Ax 
Ax FILE LEVEL INDICATORS: 
Ax 
A NDARA 
Ax 
A RCVTRNRND(15 ‘END OF DATA') 
Ax 
A 30 DETACH 
Ax 
A NDTXT(30 '30->DETACH TAR- 
A GET PROGRAM. ') 
Ax 
A RCVDETACH(35 ‘RECEIVED - 
A DETACH. ') 
Ax 
Ax 
DKK IKK I KIKI KR KKK KKK IKK RIK KK KK KKK KIKI KKK IK KIRK IK KKK KKK RK 
Ax ICF RECORD FORMATS * 
RK KKK KIKI KIKI KKK IK KK IKK RIKKI KK KK KIKI KKK KK IK KI KK KIA KKK AK 

R RCVDATA 

RCVFLD 80A 
R SNDDATA 
SNDFLD 80A 

R EVOKPGM 
A 50 EVOKE (&LIB/&PGMID) 
A PGMID 10A_ P 
A LIB 10A_ P 
A R ENDREC 
A R INVITE 
A 45 INVITE 


Figure 6-15. DDS Source File for a Batch Data Transfer Program 


[REESE OSGI CEI ISSO TOSI OSI IIIT TOI TOO ITO TTI ITI I III III IIIA. 


Ax * 
Ax ICF FILE * 
Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 
Ax * 
BRR RK KK AK AK KKK KKK KK KK AK KK KK KK KK KK KK KK KK KK KK KK KK AKA K AKA K AAA K 
A INDARA 
A R ITMRSP 
A RECID(1 'I') 
A RECITM 1 
A ITEMNO 6 0 
A DESC 30 
A QTYLST 7 0 
A QTYOH 7 0 
A qryoo 7 0 
A QTYBO 7 0 
A UNITQ 2 
A PROL 2 
A PROS 7 0 
A UFR 5 2 
A SLSTM 9 2 
A SLSTY ll 2 
A CSTTM 9 2 
A CSTTY ll 2 
A RO 5 2 
A LOS 9 2 
A FILLI 56 
A R DTLRSP 
A RECID(1 'C') 
A RCVTRNRND (90) 
A RECCUS 1 
A CUSTNO 6 0 
A DNAME 30 
A DLSTOR 6 0 
A DSLSTM 9 0 
A DSPMO1 9 0 
A DSPMO2 9 0 
A DSPMO3 9 0 
A DSTTYD 11 0 
A DEPT 3 0 
A FILL2 57 
A R DETACH 
A DETACH 
A R EOS 
A EOS 
A R EVKREQ 
A EVOKE (&LIB/&PGMID) 
A GMID 10A P 
A IB 10A P 
A R ITMREQ 
A NVITE 
A TEMNO 6 0 
A R DTLREQ 
A NVITE 
A CUSTNO 6 0 
**e* END OF SOURCE **** 


Figure 6-16. DDS Source File for a Multiple Session Program 


The following is an example of a Create Intersystem Commu- 
nications Function (CRTICFF) command used to create an 
ICF file from a DDS source file: 


CRTICFF FILE(ICFLIB/ICFFILE) SRCFILE(ICFLIB/QDDSSRC) 
SRCMBR(*FILE) ACQPGMDEV(*NONE) MAXPGMDEV(10) 
TEXT(‘ICF FILE EXAMPLE') 


The created file has the following attributes: 


e The file name is ICFFILE and it is stored in library 
ICFLIB, as specified on the FILE parameter. 


e¢ The SRCFILE parameter indicates that the DDS source 
file, from which this ICF file is created, is a member in 
file QDDSSRC in library ICFLIB. 


¢ The SRCMBR parameter indicates the source file has 
the same name as the file you are creating. 


¢ The ACQPGMDEV parameter indicates that no program 
device is automatically acquired when the file is opened. 
Your program must explicitly issue the acquire. 


¢ The MAXPGMDEV parameter indicates that up to 10 
program devices can be acquired and active with this 
file. 


e The TEXT parameter describes the file. 


The remaining parameters not specified on the CRTICFF 
command are assigned default values. Refer to Chapter 4 
and the CL Reference book for more information on these 
parameters and their default values. 


The following is an example of an ADDICFDEVE command 
used to add a program device entry to the ICF file just 
created: 


ADDICFDEVE FILE(ICFLIB/ICFFILE) PGMDEV(PGMDEVA) 
RMTLOCNAME (CHICAGO) FMTSLT(*PGM) 


The file now has a program device entry with the following 
attributes: 


¢ The PGMDEV parameter indicates that PGMDEVA is 
the program device name added to the file. This is the 
program device name used in your program. 


¢ The RMTLOCNAME parameter indicates that CHICAGO 
is the name of the remote location associated with 
PGMDEVA. CHICAGO is the remote location name 
specified on the device description when you configured 
your system for communications. 


¢ The FMTSLT parameter indicates that *~PGM is the 
format selection option used on input operations. For 
more information on this parameter, refer to “Format 
Selection Processing” on page 5-8. 


The remaining parameters not specified on the 
ADDICFDEVE command have assigned default values. 
Refer to Chapter 4 and the CL Reference book for more 
information on these parameters and their default values. 


Keyword Processing Charts 


Figure 6-17 and Figure 6-18 on page 6-22 summarize the 

DDS keywords discussed in this chapter. Use these charts 
for a quick reference when defining and creating an ICF file, 
and when writing application programs. 


Figure 6-17 lists the DDS keywords defined in this chapter 
that are supported by the various communications types for 
output operations. 


Figure 6-17 (Page 1 of 2). Output DDS Processing Keyword Support 


Asyn- Intra- 
DDS Keyword APPC SNUF BSCEL chronous system Finance Retail 
ALWWRT X X X Xx 
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Figure 6-17 (Page 2 of 2). Output DDS Processing Keyword Support 


DDS Keyword 


APPC 


SNUF 


BSCEL 


Asyn- 
chronous 


Intra- 
system 


Finance 


Retail 


CANCEL 


X 


Xx 


x2 


X 


CNLINVITE 


X 


X 


Xx 


X 


CONFIRM 


Xx 


CTLDTA 


DETACH 


x1 


DFREVOKE 
ENDGRP 


<x | | XK | OX 


EOS 


EVOKE 


FAIL 


x | Kx | &K | xX 


FMH 


<x | K | KK | XK | CX 


FMTNAME 


FRCDTA 


INVITE 
NEGRSP 


K | KX | K | KL OK | OK | OK |< | Xx 


PRPCMT 


RQSWRT 


RSPCONFIRM 


SECURITY 


<x | KK | XK | OX 


SUBDEV 


SYNLVL 


TIMER 


Kx | K | K | OK] OK | X< 


TNSSYNLVL 


VARBUFMGT3 


VARLEN 


<x | K | KK I xX 


X 


X 


X 


X 


X 


1 Use of these keywords are restricted. Refer to the Asynchronous Communications Programming book for more details. 
2 This keyword is not valid for the 3694 controller. Refer to the Finance Communications Programming book for more details. 


3 Use of this keyword is restricted. Refer to the APPC Programming book. 


Figure 6-18 lists the DDS keywords defined in this chapter 
that are supported by the various communications types for 


input operations. 


Figure 6-18 (Page 1 of 2). Input DDS Processing Keyword Support 


DDS Keyword 


APPC 


SNUF 


BSCEL 


Asyn- 
chronous 


Intra- 
system 


Finance 


Retail 


RCVCANCEL 


X 


RCVCONFIRM 


X 


RCVCTLDTA 


RCVDETACH 


RCVENDGRP 


RCVFAIL 


RCVFMH 


RCVNEGRSP 


x | K | KK I xX 
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Figure 6-18 (Page 2 of 2). Input DDS Processing Keyword Support 


Asyn- Intra- 
DDS Keyword APPC SNUF BSCEL chronous system Finance Retail 
RCVROLLB X 
RCVTKCMT X 
RCVTRNRND x x xX X 
RECID X x Xx X X x 


Figure 6-19 shows the priority sequence used by ICF in pro- 
cessing these DDS keywords and data during output oper- 


ations. 


1 Is EOS specified? 


no 


yes 


Do EOS Function 


14 


2 Is FAIL specified? 


no 


yes 


Do FAIL Function 


12 


3. Is NEGRSP specified? 


no 


yes 


Do NEGRSP Function 
(Send sense code if specified) 


12 


4 Is CANCEL specified? 


no 


yes 


Do CANCEL Function 


12 


5 Is CNLINVITE specified? 


no 


yes 


Do CNLINVITE Function 


11 


6 Is RSPCONFIRM specified? 


no 


yes 


Do RSPCONFIRM Function 


14 


7 Is RQSWRT specified? 


no 


yes 


s INVITE or READ specified? 


yes | no 
| 
Do RQSWRT Function | Do RQSWRT 
with Invite or Read | Function 
14 14 


Figure 6-19 (Part 1 of 2). Keyword Processing Chart 


8 Is EVOKE specified? 


no yes 


1 


ncorporate DFREVOKE, SECURITY, and SYNLVL keywords 


s user data specified? (Not program initialization 


parameters) 
yes | no 
Do EVOKE Function | Do EVOKE 
(Incorporate FMH keyword | Function 
and program initial- | (Incorporate 
ization parameters if | rest of 
specified) | keywords and 
| program 
| initialization 
14 parameters 
appropriately) 


9 Is TIMER specified? 


no yes 


14 


Do TIMER Function 


10 Is PRPCMT specified? 


no yes 


14 


Perform PRPCMT function 


11 Process data (Incorporate VARLEN keyword) 


(Incorporate VARBUFMGT keyword) 


12 Is DETACH specified? 


no yes 


yes 


Do 


(A 
if 


14 


13 Is INVITE, ALWWR 
no yes 


Per 
Per 
Per 
Per 
Per 
Per 
Per 
Per 
Per 
Per 


14 


14 END 


DETACH Function 
with CONFIRM 


s CONFIRM specified? 


no 


Do DETACH function 
without CONFIRM 


FMTNAME keyword 


specified) 


| 
| 
| 
| 
| 
so process format name | 
| 
| 
4 


1 


» ENDGRP, FMH, SUBDEV, FMTNAME, FRCDTA, 
CONFIRM or GET specified? 


orm INVITE or GET function if specified 
orm ALWWRT function if specified 

orm ENDGRP function if specified 

orm FMH function if specified 

orm SUBDEV function if specified 

orm FMTNAME function if specified 

orm FRCDTA function if specified 

orm CONFIRM function if specified 

orm TNSSYNLVL function if specified 
orm CTLDTA function if specified 


Figure 6-19 (Part 2 of 2). Keyword Processing Chart 
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Chapter 7. Using System-Supplied Communications Formats 


This chapter defines the system-supplied communications 
formats you can use in your program to control data commu- 
nications with the remote system. These system-supplied 
formats are used in place of user-defined data description 
specifications (DDS) record formats on the write operation. 
This chapter also maps these system-supplied communica- 
tions formats to their DDS keyword counterparts in 

Figure 7-24 on page 7-21. 


Programming examples are included to show you how these 
system-supplied formats are used. These examples are 
program segments only. You can find complete ILE C, 
COBOL/400., and RPG/400 programming examples in 
Chapter 9 through Chapter 11. 


All system-supplied formats described in this chapter may not 
be supported by the communications type you are using. 
Figure 7-23 on page 7-20 summarizes the support provided 
by each communications type. For more detail, refer to the 
appropriate communications programming book for the com- 
munications type you are using. 


General Description 


You can use system-supplied formats for communications 
only when using an ICF file. You can either create your own 
file or use the default file provided by ICF for communica- 
tions when using system-supplied formats. This file, 
QICDMF,, is in library QSYS. You must still perform the 
override commands for QICDMF to define your program 
device names. 


The QICDMF file was created with the following character- 
istics: 
e¢ The INDARA keyword is used in this file; therefore, a 
separate indicator area must be specified in your 
program when this file is used. 


e *NONE was specified for the ACQPGMDEV parameter. 
Therefore, no program device is acquired when the file 
is opened. 


¢ The maximum record length for the file is 4096 bytes. 
The maximum record length is used in allocating I/O 
buffers. If your program does not need this large a 
record, you may want to override this value by using the 
Override Intersystem Communications Function File 
(OVRICFF) command, specifying the MAXRCDLEN 
parameter. 


e The maximum number of program devices that can be 
acquired with this file is five. If your program uses more 
than five program devices, you will need to change this 
file by using the Change Intersystem Communications 
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Function File (CHGICFF) command and specifying a 
larger value for the MAXPGMDEV parameter. 


¢ 30 SECONDS was specified for the WAITFILE param- 
eter. 


e *NOMAX was specified for the WAITRCD parameter. 
e *NO was specified for the SHARE parameter. 


e *USE was specified for the AUT parameter. Refer to the 
Security — Reference book for information on what rights 
this characteristic provides. 


Do not change this file with the CHGICFF command unless 
you need to change the maximum number of program 
devices or want to provide different default characteristics 
system-wide than those provided at file creation. Use the 
Override Intersystem Communications Function File 
(OVRICFF) command to temporarily override any character- 
istics needed by a particular application. 


Do not add any program device entries to the file using the 
Add Intersystem Communications Function Device Entry 
(ADDICFDEVE) command. Define program device entries 
using the Override Intersystem Communications Function 
Device Entry (OVRICFDEVE) command. 


The primary communications functions you can perform 
using system-supplied formats are: 


e Evoke functions (starting remote programs) 
¢ Output functions (sending data) 
e Detach functions (ending communications transactions) 


e End-of-session functions (ending the session) 
These functions are described on the following pages. 


All of the system-supplied formats are specified on output 
operations. The system-supplied formats that allow you to 
perform the invite and timer functions do, however, affect 
input processing. 


Note: This chapter discusses only how you can use 
system-supplied formats to do specific communications func- 
tions, such as starting and stopping a communications trans- 
action and sending data. Your program will, of course, need 
to perform additional operations such as starting a session 
and receiving data. Refer to the appropriate sections in 
Chapter 5 for information on these operations. 


Starting a Program on the Remote System 


The target program must be started before communications 
can begin between your program and a target program. To 
start a target program and to start a communications trans- 
action, your program must issue an evoke function. 


nications transaction, without allowing the target program 


Evoke 
to communicate in return. Refer to “Ending a Commu- 
You can use one of the following three system-supplied nications Transaction” on page 7-17 for more informa- 
formats to perform an evoke function: tion on the detach function. 
¢ Evoke ($$EVOKNI). Starts the specified program on Figure 7-1 shows how to start a target program on the 
the remote system. Your program remains in send remote system. 
state, so it can send data to the target program. The source program uses an evoke function to start 
¢ Evoke with Invite ($$EVOK). Starts the specified the program at the remote system. 
program on the remote system and invites that program EZ The evoke parameters, including program name, library 
to send data. name, and security information, are sent to the remote 
¢ Evoke with Detach ($$EVOKET). Starts the specified system. 


program on the remote system and ends the commu- 


AS/400 System 


ICF 
Source Data Communications 
Program Management Support 
e 
7 Program Start 
e Request to 
Write with Remote System 
4 | $$EVOKNI I 
| 
2 | > LLL & LIL > | Data Link 
Return Code TT ed 
<Q ——_— | 


Answer from 
Remote System 


RSLS670-2 


Figure 7-1. Starting a Target Program 
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A successful completion return code tells the source 
program that the evoke function was accepted and a 
program start request was sent to the remote system. 
If the program start request is successful, both the 
program at the remote system and the communications 
transaction are started. 


You must specify an evoke parameter list in the output 
buffer with an evoke function. The evoke parameter list con- 
tains information for the remote system, such as what 
program to start on the remote system. Specify the field 
parameters in that list using the format shown in Figure 7-2. 


Figure 7-2. Evoke Parameter List 


Positions Field Description 


1 through 8 The name of the program to be evoked 


(left-adjusted) 


The password you use to sign on the 
remote system (left-adjusted) 


9 through 16 


17 through The user identifier you use to sign on the 

24 remote system (left-adjusted) 

25 through The name of the remote system library that 

32 contains the program to be evoked (left- 
adjusted) 

33 through Reserved 

52 

53 through The length of data (program parameters) 

56 

57 through Program initialization parameters 

XXXX 


If a field is not used, enter the correct number of blanks for 
the unused field. 


If multiple program initialization parameters are used, the 
program is responsible for using the proper separation char- 
acters for the remote system. For example, if the remote 
system is an AS/400 system, multiple parameters must be 
separated by a comma. 


If the remote system is another AS/400 system, the program 
parameters are passed to the target program as if they were 
passed from a Call a Program (CALL) command. Data sent 
with an evoke function are parameters used by the target 
program. 


System-supplied formats do not allow a synchronization level 
of CONFIRM and always revert to the default synchronization 
level of NONE. 


The following is an example of an ILE C write statement that 
can be used to issue an evoke. 


struct { 
char program_name??(8??) ; 
char password??(8??); 
char user_id??(8??); 
char library_name??(8??); 
char filler??(20??); 
char data_length??(4??); 
char data??(1000??); 

} evoke_rec; 


_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$EVOKNI"); 
/* Set evoke w/no invite format */ 
_Rpgmdev(icffptr, "CM1"); 
/* Set default device to CM1 */ 


_Rwrite(icffptr, &evoke_rec, sizeof(evoke_rec));/* Do the evoke */ 


The following is an example of a COBOL/400 WRITE state- 
ment which can be used to issue an evoke. 
01 DATA-RECORD. 


03 PROGRAM-NAME PIC X(8). 

03 PASSWORD PIC X(8). 

03 USER-ID PIC X(8). 

03 LIBRARY-NAME PIC X(8). 

03 FILLER PIC X(20). 

03 DATA-LENGTH PIC 9(4). 

03 THE-DATA PIC X(256). 

WRITE TRANSACTION-RECORD FROM DATA-RECORD, 


FORMAT IS '$$EVOKNI', TERMINAL IS ICF-PGMDEV. 


Figure 7-3 on page 7-4 is an example of an RPG/400 output 
specification used to issue an evoke function. 
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International Business Machines Corporation 


RPG OUTPUT SPECIFICATIONS 


GX21-9090-4 UM/050* 
Printed in U.S.A. 


12 75 76 77 78 79 80 
Program Keying Graphic Card Electro Number Poge of Progra a. 
Programmer Date Key 
O ~ sksaes Skip Output Indicators Commas | Zero Balances No Sign] CR _ | x= Remove 
als to Print Plus Sign 
S 3 Riel Name Y = Date 5-9. 
L125 EXCPT Nome Yes Yes 1 Al J Field Edit | User 
g Filename ©, “ls 5 Pea Yes No 2 B | K | Z=Zero Defined 
tine [JE Record Nome Fle =), ‘ue aT x] Position No ue? . cyt Suppress 
€ plelc] s 8 o| S| in No No 4 D M 
e olo| ® | = a oi 8/2] output ea 
So [aes [8 * 2S] Record 5 ‘onstant or Edit Word 
ai po te ake ej tea ae ea c Pee Aon cutane a Maee Emote 
3 4 5/6/7 8 9 10 1112 13 ]14]15]16]17] 18) 19 20]21 22 2 3!24! 25)26 !27!28 29!30) 31/32 33 34 35 36 3738)359/40 41 42 43/44/45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70] 71 72 73 74 
neclelereuce ella deh Bi cee MoMedh Mas che ola Ae es ee 
oz! fol titi POE eal Pissevionwe 
oft fol TET Sel iil 
o141 fof rt ii td pesca Eerste ate pt epee | 1 12 MIKE | ttt bette te tee te Ete tet tt Pt 
salah tits ett he) tity eerie) lot lal piulelelplaglagt ta bb th tae hel byt 
OrS) NO) eden ee hd rea dora pa Pl ea ee 1 12 OPO BI 1 a dod boleh PA A a a ee 
ao Pe BES BUS EEUGREERSE CUA ENEC CUR UEeSee EPEC SOL SERRUERS Eu ERT 
018i JO] ri ttt fet) ta Od? ke aie || sale | See oP | 1616 MINQ@! IAiNg4ioiti iti ti tai ttt tt at Pt 
Beto dks lee alle neni aan LETT mele itl ol egret pine are MMe ae Pie crac as 
RSLS 184-1 
Figure 7-3. Evoke RPG/400 Output Specification 
. function-management-header and an invite to the remote 
Sending Data : 
program. 
A data record can be sent from your program to the remote * Send with End-of-Group ($$SENDE). Sends a data 
program. The following list describes each of the system- record to the remote program and tells the remote 
supplied send formats that can be used to send data: program that the record is the last in a group or chain of 
¢ Send ($$SENDNI). Sends one data record to the roCOres 
remote program. e Send with Detach ($$SENDET). Sends a data record 
¢ Send with Invite ($$SEND). Sends one data record to to the remote sedi eh tells the aaiee pieeedndis 
the remote program and issues an invite to the remote ean sla Ye ah he neque Gren Ons oe pie 
program. Your program must use an input operation to Se aia padi e i wees a aba 
receive the data sent from the remote system. Oe es ee tne 
page 7-17 for more information on the detach function. 
¢ Send with Function-Management-Header 
($$SENDNF). Sends a data record that includes a oe arma secant oo you or 
function-management-header to the remote program. oe ie at . ft an ae ie ally Oh me.proceding 
Function-management-header data contains control UNCHONS MM OUPS ened ally Cala. 
neal that tells the remote system about the data Figure 7-4 on page 7-5 shows how to use system-supplied 
eg oer: formats to send data. 
¢ Send with Function-Management-Header and Invite 
($$SENDFM). Sends a data record that includes a 
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AS/400 System 


ICF 
Source Data Communications 
Program Management Support 
e 
e 
e 
1 | Write with 
Data ls S t 
$$SENDNF s 7 - Syen eee 
Return Code Data 
Includes 
. FMH 
Data Link 
e 
- Zz. 
Write with, [ee es —===> 
SSSENDNI 
2 | Return Code Data 
Write with 
E> Ps > 
$$SENDE Bs 
Return Code Data with 
End-of-Group 
Indicator 


Figure 7-4. Using $4SENDNF, $$SENDNI, and $$SENDE to Send Data 


F¥ = Your program sends a record to the remote system 
and, with the $$SENDNF communications format, indi- 
cates that the first part of the data is function- 
management-header data. The 
function-management-header data contains information 
about the user data that follows. 


EZ sYour program continues sending data records to the 
remote system. Your program uses the $$SENDE 
communications format on the last record to indicate it 
is the last in this group of records. 


Each of the preceding functions requires the fields shown in 
Figure 7-5 in the output buffer. 


Figure 7-5. Required Output Fields 


Positions Description 


1 through 4 


5 through xxxx 


Length of user data (in decimal) 


The user data to be sent 


The following is an example of an ILE C write statement that 
sends one data record. 


RSLS671-3 


struct { 
char record_length?? (42?) ; 
char data??(80??); 

} data_rec; 


_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$SENDNI") ; 
/* Set write w/no invite format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


strncpy(data_rec.record_length, "0080", 4);/*Set record length*/ 
_Rwrite(icffptr, &data_rec, sizeof(data_rec));/* Do the write */ 


The following is an example of a COBOL/400 WRITE state- 
ment that sends one data record. 


01 DATA-RECORD. 
03 RECORD-LENGTH 
03  THE-RECORD 


PIC 9(4). 
PIC X(256). 


WRITE TRANSACTION-RECORD FROM DATA-RECORD, 
FORMAT IS '$$SENDNI', TERMINAL IS ICF-PGMDEV. 


Figure 7-6 on page 7-6 is an example of an RPG/400 output 
specification to send one data record. 
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RPG OUTPUT SPECIFICATIONS ah ifousosd ua peee 


Figure 7-6. Send RPG/400 Output Specification 


Receiving Data 


You can use two operations to receive data: read and read- 
from-invited-program-devices. In addition, you can use the 
invite and timer functions to provide additional functions 
when receiving data. 


The read operation receives data from the program device 
you specify. This operation differs from the read-from- 
invited-program-devices operation, which receives data from 
any program device with a previously issued invite. 


Invite 


The invite function prepares your program to receive data. 
You can use one of the following system-supplied formats (in 
combination with other functions) to perform an invite func- 
tion: 

¢ Evoke with Invite ($$EVOK). Starts the specified 


program on the remote system and invites that program 
to send data. 


* Send with Invite ($$SEND). Sends one data record to 
the remote program, and issues an invite to the remote 
program, asking it to send. Your program must issue an 
input operation to receive the data sent from the remote 
program. 


e¢ Send with Function-Management-Header and Invite 
(SENDFM). Sends a data record that includes a 
function-management-header to the remote program, fol- 
lowed by an invite. 


* Cancel with Invite (S$$CANL). Cancels the current 
chain of data, then invites the remote program to send 
its own data. Refer to “Problem Notification” on 
page 7-8 for more information about the cancel function. 
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¢ Negative Response with Invite ($$NRSP). Sends a 
negative-response indication to the remote program, fol- 
lowed by an invite. Refer to “Problem Notification” on 
page 7-8 for more information about the negative- 
response function. 


e Request-to-Write with Invite ($$RCD). Sends a 
request-to-write indication to the remote program, fol- 
lowed by an invite. Refer to “Additional System-Supplied 
Formats” on page 7-13 for more information about the 
request-to-write function. 


Refer to “Starting a Program on the Remote System” on 
page 7-1, “Problem Notification” on page 7-8, and “Addi- 
tional System-Supplied Formats” on page 7-13 for informa- 
tion about the output format of these functions. 


Note: You can use the $$SEND communications format 
with an output length of zero to issue an invite function by 
itself. 


The read-from-invited-program-devices operation is a com- 
panion to the invite function. After issuing an invite function, 
use the read-from-invited-program-devices operation to 
receive data from the remote system. 


Note: When a program device is invited, it is recommended 
that a read-from-invited-program-devices operation be per- 
formed rather than a read operation to receive data. Perfor- 
mance may be degraded if your program issues multiple 
read operations to invited program devices. 


You do not need to issue an invite function before a read 
operation to receive data. However, if an invite is out- 
standing for a program device to which a read is issued, the 
read completes the invite and receives the data. 


Refer to Chapter 5 for additional information about the read 
and read-from-invited-program-devices operations and their 
relationship to the invite function. 


Timer 


Your program can use the timer function to set a timer before 
performing a specified function, such as a read-from-invited- 
program-devices operation. The timer function specifies an 
interval of time (in hours, minutes, and seconds) to wait 
before your program receives a timer-expired (0310) return 
code. 


Use the $$TIMER system-supplied format to issue the timer 
function. The output field for the timer request must be in 
the following format: 


hhmmss 
where hh is hours, mm is minutes, and ss is seconds. 


The following is an ILE C example that shows how to use 
$$TIMER and set the timer to 30 seconds. 


_RFILE *icffptr; /* Pointer to the ICF file */ 
icffptr = _Ropen("ICFFILE","ab+ indicators=y riofb=y"); 
_Rformat(icffptr, "$$TIMER"); /* Set timer format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 
_Rwrite("000030", 6); /* Issue timer function */ 


_Rreadindv(icffptr, &record, sizeof(record), _ DFT); 
/* Issue RFI */ 


/* See if the timer ended by checking 0310 return code */ 


88 
) 


if (strncmp(_Maj_Min_rc.major_rc, "03", 2 


) == 0 
strncmp(_Maj_Min_rc.minor_rc, "10", 2) == 0 


timer_exp(); /* Timer ended, call timer_exp */ 


/* routine to handle the time out */ 


The following is a COBOL/400 example that shows how to 
use $$TIMER and set the timer to 30 seconds. A read-from- 
invited-program-devices operation is used to receive the 
data. The return code must be checked for the timer-expired 
return code. 


01 TIMER PIC X(6) VALUE '000030'. 


WRITE TRANSACTION-RECORD FROM TIMER, 
FORMAT IS '$$TIMER', TERMINAL IS ICF-PGMDEV. 


READ TRANSACTION-FILE, 
IF RETURN-CODE EQUAL '0310', 
THEN 
GO TO TIMER-EXPIRED. 


Your program continues to run, and all operations and func- 
tions are valid during the time interval. Your program must 
issue a read-from-invited-program-devices operation some 
time after it has issued the timer function, so it can accept 
the timer-expired return code. 


Only one time interval can be maintained for your program. 
If a previous timer function has been issued and the timer 
has not yet ended, the old time interval is replaced by the 
new interval. 


The timer function can be used to vary the maximum amount 
of time that a read-from-invited-program-devices operation 
will wait for a response. When the time interval set by the 
TIMER keyword is in effect, the value specified for the 
WAITRCD parameter on the CRTICFF command is ignored. 


There is a minor difference between the functions of the 
$$TIMER format and the WAITRCD parameter. When a 
write operation is done using the $$TIMER format, the timer 
starts immediately. The time interval is no longer in effect 
when a subsequent read-from-invited-program-devices oper- 
ation completes or when the end of the interval is reached. 
When the WAITRCD parameter is used, the timer starts 
when a read-from-invited-program-devices operation is per- 
formed. 


You can use the timer function to retry other operations that 
may not be successful, possibly because of a temporary lack 
of resources (for example, during an acquire operation). To 
do this, issue the timer function, and then perform read-from- 
invited-program-devices operations until the timer ends. (The 
read-from-invited-program-devices operation allows the 
program to continue receiving input from other invited 
program devices while waiting for the timer.) 


Refer to Chapter 5 for additional information on the read- 
from-invited-program-devices operation and its relationship to 
the timer function. 


Figure 7-7 on page 7-8 is an example of using RPG/400 
programming language to enter the value on the output spec- 
ifications to set the timer for 30 seconds. 
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Figure 7-7. Timer RPG/400 Output Specification 
wee . munications format when your program is receiving data and 
Problem Notification ee se g 
detects an error. 
The following are the system-supplied formats that may be Your program is receiving data from the remote 
used to indicate that some type of error has occurred. program. 
EZ While receiving data, your program determines that it 
Fail must send a fail indication to the other program. A 
write with the $$FAIL communications format is used to 
Use the fail to indicate that your program detected an send the fail indication. 
abnormal condition while sending or receiving data. Use the A message or data is then sent (write operation) to tell 


$$FAIL system-supplied format to issue a fail. No data can 


the other program why you sent the fail. 
be sent with the fail. prog yy 


Figure 7-8 on page 7-9 shows how to use the $$FAIL com- 
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Figure 7-8. Using $$FAIL to Send an Error Signal 


No output fields are associated with the $$FAIL communica- 
tions format. 


The following is an ILE C write statement example that sends 
a fail indication. 
_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = _Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$FAIL"); /* Set fail format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


_Rwrite(icffptr, NULL, 0); /* Send the fail */ 


Program 
Devices. emcee cede WILLLLN a 
and Data 
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$$FAIL Return Code Sent to Other 
Program 
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The following is a COBOL/400 WRITE statement example 
that sends a fail indication. 


WRITE TRANSACTION-RECORD, 
FORMAT IS '$$FAIL', TERMINAL IS ICF-PGMDEV. 


Figure 7-9 on page 7-10 is an example of an RPG/400 
output specification to send a fail indication. 
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Use the cancel function to cancel the current chain of data 
(group of records) that is being sent to the remote program. 
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perform the cancel function: 


AS/400 System 


send its own data. 


an error. 


Cancel ($$CANLNI). Cancels the current chain of data. 


ICF 
Data 


Management 


(Write with 


SS$SENDNI 
Return Code 


Write with 


S$S$SENDNI 
Return Code 
XM 
( so 
2 | , 3 
L so 


Write with 
SSCANLNI 


Write with 
SSSENDNI 


Return Code 


Communications 


Support 


————— > 


Figure 7-10. Using $$CANL to Send an Error Indication 
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Cancel with Invite ($$CANL). Cancels the current 
chain of data, and then invites the remote program to 


Figure 7-10 shows how to use the $$CANLNI communica- 
tions format when your program is sending data and detects 
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Your program is sending data to the remote system. 

HE sYour program checks the data and determines that 
something is wrong with it. 

A write operation with the $$CANLNI communications 


format is used to tell the remote system to discard the 
data you have sent. 


Your program can send a message indicating the 
problem, send the data again, receive more data, or 
end the transaction. 


No output fields are associated with the $$CANLNI and 
$$CANL communications formats. 


The following is an ILE C write statement example that 
cancels the current chain of records. 


Intemational BusinessMachinesC orporation 


RPG OUTPUT SPECIFICATIONS 


_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$CANLNI");/* Set cancel w/no invite format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


_Rwrite(icffptr, NULL, 0); /* Send the cancel */ 


The following is a COBOL/400 WRITE statement example 
that cancels the current chain of records. 


WRITE TRANSACTION-RECORD 
FORMAT IS '$$CANLNI', TERMINAL IS ICF-PGMDEV. 


Figure 7-11 is an example of an RPG/400 output specifica- 
tion to cancel the current chain of records. 


GX21-9090-4UM/ 050" 
Printed inU.S.A 


Figure 7-11. Cancel RPG/400 Output Specification 


Negative-Response 


Your program uses the negative-response function to indi- 
cate it detected something wrong with the data it received. 
You can use two system-supplied formats to issue the nega- 
tive response function: 


¢ Negative-Response ($$NRSPNI). Sends a negative- 
response indication to the remote program. 
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* Negative-Response with Invite ($$NRSP). Sends a 
negative-response indication to the remote program, fol- 
lowed by an invite. 


Your program must use an input operation to determine the 
action taken by the remote program after issuing a negative 
response. You can send 8 bytes of user data (sense data) 
indicating the reason for the negative response with the 
negative-response indication. 


Figure 7-12 on page 7-12 shows how to send a negative 
response with a sense code to the remote system. 
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Figure 7-12. Using $$NRSP to Send an Error Condition 


F¥ = Your program finds the data it is receiving is not 
correct. 


Es The program sends a negative response, by issuing a 
write with the $$NRSPNI communications format, to 
the remote system including the sense data 08110000. 
The negative response tells the remote system that the 
data received is wrong, and the sense data 08110000 
asks the remote system to cancel the current group of 
data records. 


The negative-response function requires the fields shown in 
Figure 7-13 in the output buffer: 


Figure 7-13. Sense Data Format 


Positions Description 

1 Indicates whether sense data is being sent: 0 or 
blank indicates that no sense data is being sent; 8 
indicates that sense data is being sent. 

2 through 9 The sense data sent with the negative response. 


The first four positions of the sense data must 
begin with 10xx, 08xx, or 0000. The last four posi- 
tions are user-defined. 


For more information about the allowed sense values, refer 
to the appropriate communications programming book for the 
communications type you are using. 
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The following shows an ILE C write statement that sends a 
negative (-) response with invite function that includes the 
sense data 08110000. 


struct { 
char length; 
char data??(8??); 
} neg_resp_rec = {"8", "08110000"}; 


_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_RFORMAT(icffptr, "$$NRSP");/* Set negative response format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


/* Send negative response with sense data */ 
_Rwrite(icffptr, &neg_resp_rec, sizeof(neg_resp_rec)); 


The following shows a COBOL/400 WRITE statement that 
sends a negative response with invite function that includes 
the sense data 08008000. 


01 NEG-RESP-REC. 
03 REC-LEN 
03 RESP-DATA 


PIC X(1) VALUE '8'. 
PIC X(08) VALUE '08008000'. 


WRITE TRANSACTION-RECORD FROM NEG-RESP-REC, 
FORMAT IS '$$NRSP', TERMINAL IS ICF-PGMDEV. 


Figure 7-14 on page 7-13 shows the RPG/400 output spec- 
ifications you can use to send a negative response that 
includes the sense data 08110000. 
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Figure 7-14. Negative-Response RPG/400 Output Specifications 
. 
Additional System-Supplied Formats Request-to-Write 


You can use the following additional system-supplied formats 
to perform specific tasks when communicating with the 
remote system. 


Positive-Response 

Use the $$POSRSP system-supplied format to send a posi- 
tive response to the host system when you are using the 
SNUF protocol. Using this format can increase your 
application’s performance when the host is waiting for a 
response. Refer to the SNA Upline Facility Programming 
book for more information. 


Your program uses the request-to-write function to indicate 
that it wants to send something to the remote program rather 
than to continue receiving data. 


Use the $$RCD system-supplied format to issue the request- 
to-write function. This format issues the request-to-write with 
an invite. After you issue the request-to-write, your program 
must continue to receive data until it receives a return code 
indicating that the remote system is ready to begin receiving 
data. The request-to-write function has no additional associ- 
ated parameters or data. 
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Figure 7-15. Using $$RCD to Request Write 


Figure 7-15 shows how to use the $$RCD communications 
format to request permission to send. 
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Your program is receiving data from the remote 
system. The first program processes the data 
received, then receives data again. 


At some time while data is being received, your 
program determines that it needs to send a message 
to the remote system. A write with the $$RCD commu- 
nications format is used to ask the remote system to 
stop sending so your program can send the message. 


After issuing the request-to-write, your program must 
continue receiving data until it gets a return code indi- 
cating that the remote system is ready to receive. To 
continue receiving, your program issues another read- 
from-invited-program-devices operation. 


Another invite function and another read-from-invited- 
program-devices operation are issued to continue 
receiving data. 


ICF Programming V4R1 
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When the remote system is ready to receive, it sends 
one more data record with a change-direction indi- 
cation. The record says the remote system is now 
ready to receive data or, as in this example, a 
message. 

A write with the $$SEND communications format is 


used to send the message to the remote system and 
ask the remote system to continue sending data. 


No output fields are associated with the $$;RCD communica- 
tions format. 


When your program receives a request-to-write indication 
from the remote system, a code is set in the input/output 
(l/O) feedback communications-dependent section. Refer to 
Figure C-5 on page C-3 for more information about where 
this field is in the I/O feedback area. 


The code indicates the following conditions: 


0 
1 


Continue sending as normal. 
A request-to-write has been received. 
For more specific information on what this code means for 


the communications type you are using, refer to the appro- 
priate communications programmer’s book. 


The following is an example of an ILE C write statement to 
request the remote system to stop sending data. 
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_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$RCD"); /* Set request-to-write format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


_Rwrite(icffptr, NULL, 0); /* Send the request-to-write */ 


The following is an example of a COBOL/400 WRITE state- 
ment to request the remote system to stop sending data. 


WRITE TRANSACTION-RECORD, 
FORMAT IS '$$RCD', TERMINAL IS ICF-PGMDEV. 


Figure 7-16 is an example of an RPG/400 output specifica- 
tion to request that the remote system stop sending data. 


GX21-9090-4 UM/050« 
Printed in U.S.A, 


Figure 7-16. Request-to-Write RPG/400 Output Specification 
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Figure 7-17. Using $§CNLINV to Cancel an Invite 


Cancel-Invite 


Your program uses the cancel-invite function to cancel any 
valid invite for which no data has yet been received. Use the 
$$CNLINV system-supplied format to issue the cancel-invite 
function. 


Figure 7-17 shows how to use the $$CNLINV communica- 
tions format to issue the cancel-invite function. 


F¥ = Your program issues an invite to receive data from the 
remote program, then continues processing. 


EZ sYour program can cancel the invite issued previously 
using the cancel-invite function (issuing a write opera- 
tion with the $$CNLINV communications format). Your 
program must check the return code it receives to 
determine if the invite was canceled. 


If a successful return code is received, your program 
can send data. 


No output fields are associated with the $$CNLINV commu- 
nications format. 
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The following is an example of an ILE C write statement that 
issues a cancel-invite function to a program device that has 
not received input. 
_RFILE *icffptr; /* Pointer to the ICF file */ 
icffptr = _Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$CNLINV"); /* Set cancel-invite format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


_Rwrite(icffptr, NULL, 0); /* Issue the cancel-invite */ 


The following is an example COBOL/400 WRITE statement 
that issues a cancel-invite function to a program device that 
has not received input. 


WRITE TRANSACTION-RECORD 
FORMAT IS '$$CNLINV', TERMINAL IS ICF-PGMDEV. 


Figure 7-18 on page 7-17 is an example RPG/400 output 
specification to issue a cancel-invite to a program device that 
has not received input. 
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Figure 7-18. Cancel-Invite RPG/400 Output Specifications 
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Ending a Communications Transaction 


A communications transaction can be ended by your 


program or by the program at the remote system. Your job 
and the remote system your system is communicating with 


determine the program that ends the transaction. 


Communications with the remote program end when your 
program ends the transaction. However, the session may 
still exist if your program started the session. If the session 
still exists, you can end the session or you may be able to 


start another program at the remote system. 


Detach 


Use the detach function to end the transaction. The detach 


function explicitly informs the remote program that your 
program is done sending, and ends the transaction. 


You can use one of the following system-supplied formats to 
perform a detach function (in combination with other func- 


tions): 


¢ Evoke with Detach ($$EVOKET). Starts the specified 
program on the remote system and ends the transaction 
without allowing the target program to communicate in 
return. 


e Send with Detach ($$SENDET). Sends a data record 
to the remote program and ends the transaction. Note 
that not all communications types support sending a 
data record and the detach function on the same opera- 
tion. Refer to the appropriate communications book to 
determine if you can send data with the detach function. 


You can use the $$SENDET communications format with an 
output length of zero to issue a detach function by itself. 


Figure 7-19 on page 7-18 shows how to use the $$SENDET 
communications format to end the transaction. 
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Figure 7-19. Ending the Communications Transaction 


F¥ = Your program issues the detach function, by using a 
write with the $$SENDET system-supplied format, to 
tell the remote system that your program ended the 
communications transaction. 


Refer to “Starting a Program on the Remote System” on 
page 7-1 and “Sending Data” on page 7-4 for information 
about the output format of these functions. 


The following is an example of an ILE C write statement to 
issue a detach. 
struct { 
char data_length??(4??); 
char data??(80??); 
} data_rec; 


_RFILE *icffptr; /* Pointer to the ICF file */ 


icffptr = _Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


_Rformat(icffptr, "$$SENDET"); /* Set write-with-detach format */ 
_Rpgmdev(icffptr, "CM1"); /* Set default device to CM1 */ 


strncpy(data_rec.data_length, "0080", 4); /* Set record length */ 
_Rwrite(icffptr, &data_rec, sizeof(data_rec));/* Send detach */ 


7-18 —ICF Programming V4R1 


RSLS678-2 


The following is an example of an COBOL/400 WRITE state- 
ment to issue a detach. 


01 DATA_RECORD. 
03 RECORD-LENGTH PIC 9(4). 
03  THE-RECORD PIC X(256). 


WRITE TRANSACTION-RECORD FROM DATA-RECORD, 
FORMAT IS '$$SENDET', TERMINAL IS ICF-PGMDEV. 


If a detach function is issued by a target program, the EOS 
function is issued after the detach function has completed. 


This should be done since neither the EOS, Detach, or any 
other ICF function can end the session (that is, cause an 
UNBIND to be sent). 


Figure 7-20 on page 7-19 is an example of an RPG/400 
output specification to issue a detach. 
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Figure 7-20. Detach RPG/400 Output Specification 


Ending the Communications Session 


How the communications session is ended depends on 
whether your program or the remote system started the 


session. 


If your program started the session (Source program), your 
program must end the session using either the release oper- 
ation or the end-of-session function. You should primarily 
use the release operation. Use the end-of-session function 


only when you want to force the session to end. 
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The release operation ends the session only if all processing 
is complete. The end-of-session function always ends the 
session. The only possible return codes from end-of-session 
are 0000 or 830B (program device not acquired). 


End of Session 


Use the $$EOS system-supplied format to issue the end-of- 
session function. No data can be sent with the end-of- 
session function. Figure 7-21 shows how you can end the 
session by using the release operation and the end-of- 
session function. 


ICF 
Source Data Communications 
Program Management Support 
e 
e 
e 
Release Se — — > — | 
| 
Return Code 
—— <ee 
e 
e 
e 
Write with  — — — — — 
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—SsSeeS es ——Z. 


Figure 7-21. Using the Release Operation and End-of-Session Function 
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Your program uses the release operation to end the 
current communications session. 


was ended or an error occurred while trying to end the 
session. If, for example, all transactions have not 
ended when the release operation is issued, an error 
occurs and the session is not ended. 


If an error occurs and normal recovery is not possible, 
your program can use the end-of-session function to 


end the session. 


If the target program ends the transaction by the detach 
function, the session is ended implicitly. If the source 
program ends the transaction, the target program must issue 
an end-of-session function or go to the end of the job to end 
the session. 


The end-of-session function always ends the session. 
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The return code tells your program whether the session 


RPG OUTPUT SPECIFICATIONS 


No output fields are associated with the $$EOS communica- 
tions format. 


The following is an example of an ILE C write statement 
specifying the $$EOS format. 


_RFILE *icffptr; /* Pointer to the ICF file */ 
icffptr = Ropen("ICFFILE","ab+ indicators=y riofb=y"); 


/* Set end-of-session format */ 
/* Set default device to CMl */ 


_Rformat(icffptr, "$$E0S") ; 
_Rpgmdev(icffptr, "CM1"); 


_Rwrite(icffptr, NULL, 0); /* Send an end-of-session */ 


The following is an example of a COBOL/400 WRITE state- 
ment specifying the $$EOS format. 


WRITE TRANSACTION-RECORD, 
FORMAT IS '$$E0S', TERMINAL IS ICF-PGMDEV. 


Figure 7-22 is an example of an RPG/400 output specifica- 
tion to issue the end-of-session function using the $$EOS 
format. 


GX21-9090-4 UM/050« 
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Figure 7-22. End-of-Session RPG/400 Output Specification 
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System-Supplied Format Support 


Figure 7-23 shows which system-supplied formats are supported by each communications type. 


Note: APPC support applies to APPC over TCP/IP, as well. 


Figure 7-23 (Page 1 of 2). System-Supplied Format Support 


System- 

Supplied 

Format APPC SNUF BSCEL Async Intra- system Finance Retail 
$$CANL X X x1 Xx 
$$CANLNI x Xx x1 x 
$$CNLINV x X Xx Xx X x 
$$EOS xX X Xx X x 
$$EVOK Xx x X Xx Xx x 
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Figure 7-23 (Page 2 of 2). System-Supplied Format Support 


System- 

Supplied 

Format APPC SNUF BSCEL Async Intra- system Finance Retail 
$$EVOKET Xx x X Xx Xx x 
$$EVOKNI Xx x X X Xx x 
$$FAIL Xx x X Xx Xx X 

$$NRSP x Xx x 
$$NRSPNI x Xx X x 
$$POSRSP x 

$$RCD Xx x X xX 

$$SEND X xX X Xx Xx X x 
$$SENDE X X X xX 
$$SENDET Xx x X Xx x 
$$SENDFM Xx X X xX 
$$SENDNF x Xx Xx X x 
$$SENDNI Xx x X X Xx X x 
$$TIMER xX x X Xx Xx X x 


1 These keywords are not valid for the 3694 controller. Refer to the Finance Communications Programming book for more details. 


Mapping System-Supplied Formats to DDS 
Keywords 


Figure 7-24 maps system-supplied formats to DDS 
keywords. 


Figure 7-24. Mapping of System-Supplied Formats to DDS 
Keywords 


System-Supplied 


Formats DDS Keywords 

$$CANL CANCEL with INVITE 

$$CANLNI CANCEL 

$$CNLINV CNLINVITE 

$$EOS EOS 

$$EVOK EVOKE, SECURITY, and INVITE 
$$EVOKET EVOKE, SECURITY, and DETACH 
$$EVOKNI EVOKE and SECURITY 

$$FAIL FAIL 

$$NRSP NEGRSP with INVITE 
$$NRSPNI NEGRSP 

$$POSRSP RSPCONFIRM 

$$RCD RQSWRT with INVITE 

$$SEND INVITE 

$$SENDE ENDGRP 

$$SENDET DETACH 

$$SENDFM FMH with INVITE 

$$SENDNF FMH 

$$SENDNI No DDS keywords 


Figure 7-24. Mapping of System-Supplied Formats to DDS 
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Chapter 8. Programming Considerations 


This chapter presents general communications programming 
considerations related to the ICF file. Programming consid- 
erations specific to a communications type are not discussed. 
Refer to the appropriate communications programming book 
for more information on the programming considerations for a 
particular communications type. 


Return Codes 


Return codes are used by the communications application 
program to determine the program state. Program states are 
receive, send, or exception. The program checks the return 
codes and completes the action required by the contents of 
the return codes. 


The meaning of the major ICF return codes and some exam- 
ples of minor return codes follow. These definitions help you 
determine the return codes you need to check in your 
program. For a complete list of return codes, see 

Appendix B. 


Major Codes 


All major return codes that represent normal conditions have 
values 00xx, 02xx, and 03xx. Major return codes that repre- 
sent input/output (I/O) exceptions have values of 04xx and 
34xx. Major return codes that represent error conditions 
have values 08xx, 11xx, and 80xx through 83xx. This divi- 
sion lets you quickly compare codes and determine the type 
of action required. 


The main groups of major return codes are: 


¢ Operation was successfully completed (00xx, 02xx). 


¢ Successful operation. No data was received, but some 
control information may have been received (03xx). 


¢ Output exception occurred (04xx). 
e Miscellaneous program errors occurred (08xx and 11xx). 
e Input exception occurred (34xx). 


e lIrrecoverable error occurred. The session has been 
ended and the underlying communications support may 
no longer be active (80xx). 


e lrrecoverable session error occurred. Session has been 
ended but the underlying communications support is still 
active (81xx). 


¢ Open or acquire operation failed. Session was not 
started but recovery might be possible (82xx). 


¢ Session error occurred. Recovery might be possible 
(83xx). 
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Minor Codes 


The minor part of a return code identifies the specific condi- 
tion within the general condition that is identified by the major 
part of the code. Some examples of the minor codes are: 


e A detach was received (xx08), a detach was received 
with a system message (xx18), or a detach was received 
with a confirm (xx1C). 


e An invalid evoke function was issued (xx29). 


ICF Environment Considerations 


You must understand the following considerations before you 
write programs for ICF communications: 


e Your program should check the major/minor return code 
after every operation to determine the success or failure 
of the operation. 


e Information in the open and I/O feedback areas can be 
useful to your program. Refer to Chapter 5 for informa- 
tion about these areas and Appendix C for a summary 
of the fields available in these areas. 


e A target program can communicate with the source 
program by acquiring the program device whose remote 
location name is *REQUESTER. 


e lf a target program never acquires a program device for 
the requesting program device, a diagnostic message is 
written to the job log when the target job completes. 

The message indicates that the program ended with an 
active connection to the session. The message is 
normal if there is no need for the target program to com- 
municate with the source program. If the target program 
must communicate with the source program, this 
message indicates a possible logic problem in your 
program. 


¢ For most communications types, the first I/O operation 
following the acquire by the source program must 
include an evoke function. This operation starts the 
target program on the remote system with which the 
source program is to communicate. You can start the 
target program with program initialization parameters 
specified as part of the evoke function. 


e When a single program is written to function as either a 
source or a target program, the program may need to 
determine its role (source or target). A suggested 
method of making this analysis for a program is to define 
a CALL parameter that contains one value when the 
program is started by the remote system and another 
value when the program is started by the local user or 
program. 


e A target program cannot start error recovery. If a per- 
manent session error occurs, the target program should 
finish any needed processing and end the program. The 
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source program is responsible for reestablishing the 
session and transaction. See Appendix B for more 
information about communications error recovery. 


Open or Acquire Considerations 


The following open or acquire considerations apply when you 
write programs for ICF communications: 


If an ICF file open is a subsequent open of a shared file, 
the program is attached to the already open file. The 
state and attributes of the file do not change. Refer to 
the Data Management book for more information on 
shared file processing. 


Your program can establish more than one session. 
These sessions can be to the same remote system (if 
the remote system supports multiple sessions) or to dif- 
ferent remote systems. The program device names are 
used to distinguish between sessions within your 
program. 


A program device can either be acquired automatically 
when the ICF file is opened (ACQPGMDEV = program 
device) or explicitly with the acquire operation. Only one 
program device can be acquired as part of the open 
operation. If a program is using multiple sessions, all of 
the program devices, except the first one, must be 
explicitly acquired. 


Note: With a FORTRAN/400 program, a separate ICF 
file must be used for each ICF session. FORTRAN/400 
programs can implicitly acquire a program device only 
when the ICF file is opened (ACQPGMDEV = program 
device). 


If a target program acquires a program device other than 
a program device associated with a remote location with 
the name of *REQUESTER, a new session is allocated 
and a logical link to the source program is not estab- 
lished. No error is indicated because a target program 
on one session can also be a source program on 
another session. 


Output Considerations 


The following output considerations apply when you write 
programs for ICF communications: 
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Your program should check the major/minor return code 
after every output operation to determine if the remote 
system wants to send data. You can also use a field in 
the I/O feedback to determine this information. See 
Appendix C for a summary chart of the I/O feedback 
area. 


When the program is communicating with multiple ses- 
sions, the appropriate program device name must be 
specified on the write statement in the control area 
(depending on the language used) before issuing the 
output operation. Refer to examples in Chapter 9 
through Chapter 11. 
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The output length of the operation is determined by the 
specified record format. If you use user-defined formats, 
the record format length, as determined by the record 
definition in data description specifications (DDS), is the 
output length. You can vary this output length at run 
time by using the VARLEN DDS keyword. If you use 
system-supplied formats and data is allowed as part of 
the function, the output length is specified as part of the 
record format. 


If an output operation is issued with a zero record 
length, ICF assumes that the needed functions are only 
the functions indicated by the operation specified, and 
the data is not placed in the output buffer. For example, 
if a zero-length write operation is issued with a user- 
defined format with the INVITE keyword in effect, the 
program device is invited, but no data is sent to the 
remote system. 


Multiple output operations can be done with a single 
write operation. For example, if a write operation is 
issued with a user-defined format with the FMH and 
INVITE keywords in effect, or with the system-supplied 
$$SENDFM format, data is sent to the remote system 
with FMH information and the program device is invited. 
Refer to Chapter 6 to determine the processing 
sequence of the DDS keywords. 


If your program issues an output operation with an 
output length greater than the length supported for the 
session, the operation completes with an 831F return 
code. The maximum output length supported is deter- 
mined by the communications type you are using, the 
record length specified in configuration, or the record 
length specified on the Add Intersystem Communications 
Function Device Entry (ADDICFDEVE) or Override Inter- 
system Communications Function Device Entry 
(OVRICFDEVE) command. 


If your program issues an output operation while a 
session is in receive state, the operation may complete 
with an output exception (a major/minor return code of 
0412). If the operation completes with an output excep- 
tion, the data is not sent to the remote system. Your 
program must issue an input operation to receive the 
data or system message that is pending. 


If your program issues an output operation to an invited 
program device and the communications type you are 
using supports the cancel-invite function, ICF tries to 
cancel the invite. If the invite cannot be canceled, the 
output operation completes with a 0412 return code. 


When your program is reading data from a local source, 
such as a database file, it may not determine until the 
next read that it has just read the last record in the file. 
If this is the case and your program uses a specific indi- 
cation, such as the end-of-group or detach function, to 
inform the remote system when the end-of-file indication 
is reached, then you must ensure that this end-of-file 
indication is sent with a zero-length record format. If 
not, then any data in the output buffer from a previous 


operation is sent to the remote system as user data (for 
example, the last record may be sent twice). 


Input Considerations 


The following input considerations apply when you write pro- 
grams for ICF communications: 


Your program must examine the major/minor return code 
to determine if the input operation completed with data. 
A major code of 00 indicates data reception. A major 
code of 02 indicates that data was received, but the job 
is being canceled. A major code of 03 indicates that no 
data was received. Refer to Appendix B for a complete 
summary of major/minor return codes. 


When the program is communicating with multiple ses- 
sions, the appropriate program device name must be 
specified on the read statement in the control area 
(depending on the language used) before issuing the 
input operation. Refer to examples in Chapter 9 through 
Chapter 11. 


The input length of the operation is determined by the 
specified record format. If you use user-defined formats, 
the record format length, as determined by the record 
definition in DDS, is the input length. If you use the 
system-supplied QICDMF file, the input length is always 
4096. 


When the actual length of the data received is less than 
the input length, the system pads the remainder of the 
record with blanks (except for basic conversations in 
APPC). A field in the I/O feedback area indicates the 
actual length of the data received from the remote 
system. Refer to Appendix C for a summary chart of 
the I/O feedback area. 


For most communication types, when your program 
issues an input operation that completes with a return 
code of 0000 or 0300: 


— The operation is successful. 
— Your program controls the session and can send 
data. 


When the operation completes with a return code of 
0001 or 0301: 


— The operation is successful. 
— The remote program controls the session and your 
program should continue issuing input operations. 


Response indicators (RCVTRNRND, RCVDETACH, 
RCVCONFIRM, RCVNEGRSP, RCVCANCEL, 
RCVFMH, RCVFAIL, and RCVENDGRP) can be 
received either with data or without data (indicators 
only). Your program must examine the major/minor 
return code to determine if the record contains data. 


¢ For most communications types, if an input operation is 
issued before an evoke is sent or after a detach function 
is sent or received, the operation completes with a 8327 
return code. 


e When processing input data, consideration should be 
given to detecting invalid data within a numeric field. 
The program can detect invalid data by verifying numeric 
field contents through program logic, or by permitting the 
system to detect a decimal-data error when the field is 
used in an arithmetic operation within the program. 


The format selection processing used (as determined by 
the FMTSLT parameter on the ADDICFDEVE or 
OVRICFDEVE command) determines how the record 
format name is selected to process incoming data. 


If the FMTSLT(*RECID) option is used, ICF returns the 
record format based on the data received from the 
remote system. Therefore, the proper record (the one 
that matches the data received) will be selected. 


If the layout of the record format is described within the 
program, the program logic determines the placement 
and types of fields within the record. The program is 
responsible for processing the data according to a spe- 
cific record type. 


Release, End-of-Session, and Close 
Considerations 


The following release, end-of-session, and close consider- 
ations apply when you write programs for ICF 
communications: 


Release Considerations 


The following are release operation considerations for ICF 
programs: 


e lf a target program issues a release operation, the 
logical connection between the current program and the 
communications session is ended. The communications 
session remains intact, and can, by using an acquire 
operation, be used again in the same job. The session 
state will be the same as it was when it was released. 


e lf a source program issues a release operation, the state 
of the operation is verified, and the release request can 
be rejected. If the program device is invited, the release 
operation is rejected with an 832C return code. 


If the release operation is successful, the communica- 
tions session ends. 


Note: The FORTRAN/400 language does not support a 
release operation. Instead, an end-of-session function 
or a close operation must be issued. Refer to “End-of- 
Session Considerations” and to “Close Considerations” 
for more information. 
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End-of-Session Considerations 


The following are end-of-session function considerations for 
ICF programs: 


e An end-of-session function is always successful if a 
session exists. The system ends the communications 
session regardless of the state of the session. 


e lf atarget program issues an end-of-session function, 
the session is ended and cannot be reestablished with 
an acquire operation. 


e¢ A session remains allocated to the target program until 
an end-of-session function is performed or until the job 
ends. 


e An end-of-session function issued to an unacquired 
device results in an 830B return code. 


e For conversations started using EVOKE with 
SYNLVL(*COMMIT) specified: 


— If EOS is issued after a TAKE_COMMIT_ indication has 
been received by the transaction program (TP), 
resynchronization processing is performed. 

— Inall other cases, the EOS causes the logical unit 
of work (LUW) to be put into rollback required state. 
The TP must perform a rollback operation before 
working with any other resources involved in that 
LUW. 


Close Considerations 


The following are close operation considerations for ICF pro- 
grams: 


e If a close operation is issued to a shared file, the 
program issuing the close cannot do I/O operations to 
the file, but other programs that have the file open can 
still use the file. Refer to the Data Management book for 
more information on shared file processing. 


e When a close operation is issued to an ICF file, all ses- 
sions associated with a source program for the specified 
file are ended regardless of the state of the session. 
Depending on the communications type, any buffered 
data may or may not be sent to the remote system. 


e If asession is associated with a requesting program 
device, the logical connection between the current 
program and the communications session is ended. The 
communications session remains intact, and can, by 
using an acquire operation, be used again in the same 
job. The session remains intact. The state of the 
session remains the same when the program device is 
acquired again. 


e Any active transactions associated with the file may be 
abnormally ended. 
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e Protected conversations are conversations that use 
two-phase commit protocols. Protected conversations 
must commit the current logical unit of work before they 
can end normally. If an end-of-session function is 
issued before the logical unit of work is committed, 
APPC rolls back the logical unit of work. 


e Application programs using protected conversations 
should detach the conversation before ending the 
session. The DETACH keyword issued with the 
TNSSYNLVL keyword and followed by a commit opera- 
tion causes the system to commit all changes in the 
current logical unit of work and end the conversations. 
Ignoring this advice and issuing a write with EOS when 
there are still active protected conversations causes 
APPC to do the following. 


— Issue a DEALLOCATE_ABEND on those conversa- 
tions. 
— Roll back the current logical unit of work. 


Two-Phase Commit Considerations 


The following should be considered when programming for 
two-phase commit. 


Committing Resources 


Your program requests that protected resources are com- 
mitted by using the commit operation or the PRPCMT func- 
tion. 


Your program is notified that it has received a commit 
request from the remote program in the following ways: 


e A major return code of 02 or 03 with minor return codes 
of 57, 58, or 59. 


¢ The RCVTKCMT response indicator is set. The 
RCVTRNRND and RCVDETACH response indicators 
may also be set. 


When your program receives a commit request, it must 
respond positively or negatively to the request as follows: 


e To respond positively, do a commit operation. 


e To respond negatively to the request, do one of the fol- 
lowing: 


— Do a rollback operation. 


— Issue a fail function. This causes the logical unit of 
work to be rolled back if the partner issued a 
commit operation. Otherwise, if the partner issued a 
prepare-for-commit function, your program can 
attempt error recovery. 


— Abnormally end the transaction and session by 
issuing either an end-of-session function or a close 
operation. 


Rolling Back Resources 


Your program requests that protected resources are rolled 
back by using the rollback operation. 


Your program is notified that it has received a rollback 
request from the remote program or that rollback is required 
because of an error on the conversation in the following 
ways. 


¢ One of the following return codes is received. 


— 0054 

— 0254 

— 80F9, 80FA, 80FB 

— 81F0, 81F1, 81F2, 81F3, 81F4, 81F5 
— 83FB, 83FC, 83FD, 83FE, 83FF 


¢ The RCVROLLB response indicator is set. 


When your program receives a rollback request, it must 
respond with a rollback operation. 


Exchanging Log Names 


APPC uses a mechanism called exchange log name to 
negotiate the exact two-phase commit capabilities used for a 
protected conversation. The two systems at each end of the 
conversation exchange information about their level of two- 
phase commit support. Together, they decide which func- 
tions to use. 


Exchange log name processing is performed when the 
system attempts to evoke its first protected conversation after 
communications have been established between the two 
systems. (The active session count between the two 
systems goes from 0 to 1.) The evoke is pended until the 
exchange log name processing has completed successfully. 


Exchange log name processing brings up its own session to 
do the negotiation. You need to configure the mode 
description with one extra session that the system can use 
for exchange log name processing. 


Performance 


The following are performance considerations for two-phase 
commit processing. 


¢ The first protected conversation evoke between two 
systems takes longer to complete because of the 
exchange log name processing that takes place between 
the systems. 


e¢ The user may experience slower response times due to 
the two-phase commit processing needed to process the 
commit and rollback operations. Commit and rollback 
operations are done for each transaction program in the 
two-phase commit transaction. 


e The bigger the two-phase commit transaction and the 
greater the number of commits issued for each trans- 
action, the slower the response time. 


e If data integrity is critical to your application, you should 
use two-phase commit processing. The extra pro- 
cessing that is done to ensure data integrity slows the 
performance of applications that use two-phase commit 
processing. 


Remote Program Start Considerations 


Program start requests that are received from a remote 
system result in an attempt to start the job. The program 
specified by the program start request runs within a routing 
step of the job. All jobs on the AS/400 system operate in an 
environment called a subsystem. 


In order to receive program start requests from a remote 
system and to start a job to run the program specified on the 
program start request, a subsystem must be defined on the 
AS/400 system. You can define a new subsystem, or 
change an IBM-supplied subsystem such as QBASE or 
QCMN, to receive and process program start requests. 


Refer to the Work Management book for more information 
about QBASE and QCMN. 


Defining the Environment 


Subsystem descriptions are created using the Create Sub- 
system Description (CRTSBSD) command. The CRTSBSD 
command is described in the Work Management book. 


The AS/400 system considers a communications device to 
be another source of work for a subsystem. Therefore, you 
must define a communications entry in the subsystem 
description to identify the communications devices and 
remote locations for which work (program start requests) can 
be received by the subsystem. Default communications 
entries are shipped with the system. However, you can 
change these entries with the following commands: 


e Add Communications Entry (ADDCMNE) 
e« Remove Communications Entry (RMVCMNE) 
¢ Change Communications Entry (CHGCMNE) 


You can specify a default user on the communications entry 
for a subsystem description on the DFTUSR parameter on 
the ADDCMNE command or CHGCMNE command. Refer to 
the CL Reference book for more information on the use of 
these commands. 


Use the Add Routing Entry (ADDRTGE) command to define 
the routing information for remotely started jobs. You can 
specify that the program identified in the program start 
request be used. Or, you can define routing entries that 
select the program based on the device description name, 
mode name, or user profile name. Refer to the Work Man- 
agement book for more information on the use of this 
command. 
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Handling Program Start Requests 


When a subsystem receives a program start request from a 
remote system, it locates a user profile for the job based on 
one of the following: 


e The user ID from the program start request (if one was 
specified) 


e The user ID from the DFTUSR parameter of the 
ADDCMNE command 


If the user ID is not passed as part of the program start 
request (for example, “NONE specified on the SECURITY 
keyword), the system checks the communications entry in 
the subsystem handling the program start request to see if it 
allows a default user. If the entry is not found, the program 
start request is rejected with a security violation error. 


The user profile contains the authorization to the objects and 
functions the job can reference. 


The subsystem also locates a job description for the job. 
The job description defines job attributes, such as the job 
output queue and the first library list made. You can specify 
a job description on the ADDCMNE command or in the user 
profile. 


The program name and the library name are passed as part 
of the program start request. This information is used along 
with the subsystem description routing entries to start a 
routing step and to select the program that starts running on 
the routing step. 


If a program start request is received on the AS/400 system 
with an unqualified program name, the system uses the 
library list for the subsystem handling the program start 
request. The library list for the subsystem consists of the 
values from the QSYSLIBL and QUSRLIBL system values at 
the time the subsystem was started. 


If a program start request is received on the AS/400 system 
with a qualified program name, the acceptable format varies 
by communication type. Most communication types (for 
example, asynchronous, BSCEL, and SNUF) separate the 
library and program as part of the program start request. 
Intrasystem communications allows the program name to be 
in the form library/program. APPC accepts either 
library/program or the architected form program.library. 


Note: Program and library names on the AS/400 system 
are limited to 10 characters. If you are using BSCEL to start 
a remote program, the program and library name is limited to 
8 characters. 


The subsystem searches its routing table to determine the 
name of the program to be run in the job’s routing step. In 
an interactive or batch environment, the routing data normally 
selects the program QSYS/QCMD, which processes control 
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language (CL) commands. However, QCMD does not 
process data received with program start requests, and 
should not be selected as a communications target program. 
For remotely started jobs, the program to be run is commonly 
specified on the program start request from the remote 
system. 


The subsystem also uses the routing entry to select a class 
for the job. The job class defines operation attributes, such 
as operation priority and time slice. 


The system sends message CPF1269 to the QSYSOPR 
message queue if it is unable to start the requested program. 
The information in the message can help determine and 
correct the cause of the problem when working with the 
remote system programmer. Refer to Appendix B for addi- 
tional information on the message generated for failed 
program start requests. 


When the communications target job is started and the target 
program begins running, the target job can access any 
parameters specified on the evoke request as if they were 
parameters passed on a Call a Program (CALL) command. 
The target job communicates with the source program by 
opening an ICF file, acquiring the requesting program device, 
and issuing I/O requests to read and write data. 


If program initialization parameters are passed on an evoke 
function or program start request, the following points should 
be noted: 


e If multiple program initialization parameters are passed, 
the system uses commas to separate these parameters. 
Therefore, do not include commas in your program 
initialization parameter data. 


e If you specify program initialization parameters with the 
evoke function, each parameter that is sent should be 
equal in length to the corresponding parameter specified 
in the target program. If it is longer than the parameter 
length in the target program, truncation occurs. If it is 
shorter than the parameter length in the target program, 
results may occur that cannot be predicted. 


The target job runs as a normal batch job, and is subject to 
all job control commands, such as Display Job (DSPJOB), 
Work Job (WRKJOB), and End Job (ENDJOB). The job can 
be transferred using the Transfer Job (TFRJOB) command, 
but not the Transfer Batch Job (TFRBCHJOB) command. 


Once the transaction ends (when a detach is successfully 
sent or received), the target program can no longer commu- 
nicate with the source program. For most communications 
types, if the program is started with an evoke-with-detach 
function and you do an acquire operation to the requesting 
program device, the acquire fails with a 82A9 return code. 


Figure 8-1 on page 8-7 shows a sample ICF communica- 
tions environment. 
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Figure 8-1. Sample ICF Communications Environment 
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Refer to the Work Management book for more information on 
job structures and job processing. 


Prestarting Jobs for Program Start 
Requests 


To minimize the time required to carry out a program start 
request, you can use the prestart job entry to start a job on 
the AS/400 system before the remote program sends a 
program start request. Because a job is already started and 
running before the program start request is received, 
improved program response time results. 


You can use prestart jobs for all communications types that 
support program start request processing: APPC, asynchro- 
nous, BSCEL, intrasystem, finance, retail, and SNUF com- 
munications. 


To use prestart jobs, you must define a prestart job entry and 
a communications entry in the subsystem description. Each 
prestart job entry contains a program name, library name, 
user profile, and other attributes, which the subsystem uses 
to create and manage a pool of prestart jobs. 


Both the communications and prestart job entries must be 
specified in the same subsystem. If a program start request 
is received on a subsystem that does not have a prestart job 
entry with the matching program name, the usual processing 
required to start a communications batch job occurs when 
the program start request is received. The subsystem 
attempts to allocate the communications devices that are 
identified by the communications entries. When a program 
start request is received, it is sent to the subsystem that has 
the required communications device allocated. For more 
information about adding, changing, and removing commu- 
nications entries in subsystem descriptions, refer to the Com- 
munications Management book. 


When a subsystem is initially started, prestart jobs are 
started based on the information contained in the prestart job 
entries. Each prestart job entry identifies the program that is 
to be started, the number of jobs that need to be started with 
the program, and the user profile under which the jobs will 
run when it is not servicing a program start request. 
However, when a program start request is received, the sub- 
system determines if the program name sent on the program 
start request matches the program name on one of the pre- 
start job entries. If so, the subsystem ensures that the 
program start request user ID and password are valid and 
that the user is authorized to use the device and the library 
and program. The program start request is then attached to 
a prestart job. The prestart job runs under the user profile 
specified on the program start request while it is servicing 
that request. 


Protected conversations must commit the current logical unit 
of work before they can end normally. If an end-of-session 
function is issued before the logical unit of work is com- 
mitted, APPC rolls back the logical unit of work. 
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Application programs using protected conversations should 
detach the conversation before ending the session. The 
DETACH keyword issued with the TNSSYNLVL keyword and 
followed by a commit operation causes the system to commit 
all changes in the current logical unit of work and end the 
conversations. Ignoring this advice and issuing a write with 
EOS when there are still active protected conversations 
causes APPC to do the following. 


e Issue a DEALLOCATE_ABEND on those conversations. 
e Roll back the current logical unit of work. 


Commands 


Prestart jobs can start at the same time the subsystem is 
started, or you can use the Start Prestart Jobs (STRPu) 
command to start jobs for a prestart job entry in an active 
subsystem. 


The Change Prestart Job (CHGPJ) command allows you to 
change some of the attributes for a prestart job based on 
either the attributes of the job description for a prestart job 
entry or the attributes of the job description defined in the 
user profile of a program start request. 


The End Prestart Job (ENDPJ) command allows you to end 
all jobs for a prestart job entry in an active subsystem. 


The following commands should be used when working with 
prestart job entries in the subsystem description: 


e The Add Prestart Job Entry (ADDPJE) command adds a 
prestart job entry to the specified subsystem description. 


e¢ The Change Prestart Job Entry (CHGPJE) command 
changes a prestart job entry in the specified subsystem 
description. 


e The Remove Prestart Job Entry (RMVPJE) command 
removes a prestart job entry from the specified sub- 
system description. 


e The Display Active Prestart Jobs (DSPACTPJ) command 
displays the run time statistics and performance informa- 
tion for prestart jobs associated with a prestart job entry 
in an active subsystem. 


For more information about the parameters and attributes 
associated with these commands, refer to the CL Reference 
book. 


Application Considerations 


Certain programming changes need to be made to the pre- 
start job program to allow it to be started by and communi- 
cate with the remote program. The following points must be 
taken into account when writing prestart job applications: 


e A prestart job program should do as much work as pos- 
sible, for example, allocating objects and opening data- 
base files, before attempting to acquire a requesting 
program device. Once a prestart job is started, this 
initial processing is done before the acquire of a 
requesting program device. The acquire operation 


causes the job to wait until a program start request is 
received. When a program start request is received, the 
program then continues with the acquire operation. 


e When a prestart job program is done servicing a 
program start request, it must do an end-of-session func- 
tion followed by the acquire of a requesting program 
device. This is the only way the prestart job makes itself 
available for the next program start request. If a release 
operation is performed instead of an end-of-session 
function, the acquire of the requesting program device 
does not cause the program to wait, and the program 
device continues to run on the current session. 


e Because a job is already started and running before a 
program start request with program initialization parame- 
ters is received, the subsystem stores these parameters 
in the program initialization parameter data area for the 
prestart job to which the program start request attaches. 
After the acquire of the requesting program device, you 
must use the Retrieve Data Area (RTVDTAARA) 
command (specifying “PDA as the data area) or the high 
level language Retrieve Data Area operation (for 
example, COBOL ACCEPT) to retrieve the program 
initialization parameters (if any) passed on the program 
start request. 


Note: A maximum length of 2000 bytes is allowed for 
program initialization parameters passed on a program 
start request for a prestart job. 


e Only resources that are used specifically for a trans- 
action should be deallocated. Any resource that is com- 
monly used for most transactions performed by the 
prestart job program should remain allocated while the 
job is waiting for the next request to be received. 


e When a program start request attaches to a prestart job, 
none of the attributes associated with the user profile on 
the program start request are used. To change the attri- 
butes for a job to those of the job description on the user 
profile specified on the program start request, use the 
CHGPJ command. 


¢ Your application should check for an 8209 return code 
after completion of the acquire to the requesting program 
device to determine if the prestarted job is being can- 
celed. 


See Figure 8-2 on page 8-10 for a sample prestart job 
program. For information about sharing database files in the 
same job and across jobs, see the DB2 for AS/400 Database 
Programming book. 


Security Considerations for Prestart Jobs 


When a prestart job is initially started, authority checking for 
a prestart job entry user profile is performed on every object 
that is needed to run the job. When a program start request 
attaches to a prestart job, however, it runs under the user 
profile specified on the program start request. Before a 
program start request is allowed to attach to a prestart job, 
only the program start request user ID and password and its 
authority to the communications device, library, and program 
are checked. To avoid cases where the program start 
request user profile is not authorized to objects to which the 
prestart job entry user profile is authorized, you should 
ensure that the user profile specified on the program start 
request is authorized to at least as many objects as that on 
the prestart job entry. 


To accomplish this, you can do one of the following: 


¢ Create your prestart job program when you are running 
under the prestart job entry user profile, and specify the 
value *OWNER for the user profile when you create your 
prestart jobs program. In other words, for the ILE C, ILE 
COBOL, or ILE RPG programming language, specify 
USRPRF(*OWNER) on the CRTPGM, CRTSRVPGM, 
CRTBNDC, CRTBNDRPG, or CRTBNDCBL command. 
For the COBOL/400 or RPG/400 programming language, 
specify USRPRF(*OWNER) on the CRTRPGPGM or 
CRTCBLPGM command. 


e Explicitly check for object authorization (using the Check 
Object (CHKOBJ) command) before you change or 
access any objects. 


Files and objects to which a prestart job entry user profile is 
not authorized should be deallocated before you end your 
transaction. 


Prestart Jobs Program 


Figure 8-2 on page 8-10 is a COBOL/400 prestart jobs 
program that can be used to handle program start requests. 
The initial processing, for example, opening the ICF file and 
printer file, is done first before the acquire of a requesting 
program device. The acquire operation then causes the pre- 
start job program to wait for a program start request. After 
acquiring the requesting program device, an accept is done 
to retrieve the program initialization parameters, and a CL 
program is called to change some of the job attributes based 
on the program start request user profile (using the CHGPJ 
command). After the main body of the program is done pro- 
cessing, the communications session is ended, and the 
program loops back to the acquire operation and waits for 
the next program start request to be received. 
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PROGRAM acer ep Bee ci, es Seles ee ones San ay ees PJPGM 


EVDTANYs oe eS ee ee ae a we ee 8 QNETUSER 
Source file ......... +... :  QCBLSRC 
LA DARY? <deses ere aed Gr iel a ety! Hat QNETUSER 
Source member ........... : ~~ PJPGM 03/08/90 13:04:36 
Generation severity level .....: 29 
Text 'description'......... : COBOL program for prestart job example in C.P.G. 
Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........ : + *NOMAX 
Message limit severity ......: 29 
Print file... ...... 2... . :  QSYSPRT 
LDV? “aes cio seen, So Se ok eget ieee ee *LIBL 
FIPS flagging .......... +. :  ¥*NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. .......... =. : + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release... ... 2... ~:~) *CURRENT 
User profile. ...........:  *USER 
Authority .........+.... :  ¥*LIBCRTAUT 
Compiler. ........ 4... 1. IBM AS/400 COBOL/400 
1 000010 IDENTIFICATION DIVISION. 
2 000030 PROGRAM-ID. PJPGM. 
OQOOO5O kx xR AAR KARR KAR KEKE RRR ERK RRR ER ERR RRR ERE RER ERE RRR ER RRR REE RE RERERERRE 
000060* THIS IS A PRESTART JOB TARGET PROGRAM * 
000070* THIS PROGRAM WILL LOOP FOREVER * 


QOO1L RO kx KAA KK AAR KARR RK ERE R EKER EKER KKK ERE RRR RRR ERE RRR EKER ER ERR RE 
3 000200 ENVIRONMENT DIVISION. 
4 000220 CONFIGURATION SECTION. 
5 000240 SOURCE-COMPUTER. IBM-AS400. 
6 000250 OBJECT-COMPUTER. IBM-AS400. 
7 000260 SPECIAL-NAMES. I-0-FEEDBACK IS IO-FEEDBACK 
8 000270 OPEN-FEEDBACK IS OPEN-FBA 
9 000271 PIP-DATA IS PIP-PARM. 
000280 
10 000290 INPUT-OUTPUT SECTION. 
11 000310 FILE-CONTROL. 


(COCR M Rte ee 


000312* FILE SPECIFICATIONS * 
000313* ICFFILE : ICF FILE * 
000314* QSYSPRT : PRINTER FILE * 


01003 D2 aa I IOI IO ICI ICI I I ICI ICICI RIC IR ICICI A IIR ICI IR AIR A 
12 000330 SELECT ICFFILE ASSIGN TO WORKSTATION-PJDDS-SI 
13 000340 ORGANIZATION IS TRANSACTION 
14 000360 FILE STATUS IS STATUS-IND MAJ-MIN. 
15 000370 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 


Figure 8-2 (Part 1 of 3). COBOL/400 Coding for a Prestart Job Program 
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000420 DATA DIVISION. 
000440 FILE SECTION. 


000500 FD ICFFILE 

000510 LABEL RECORDS ARE STANDARD. 

000520 01 ICFREC. 

000530 COPY DDS-ALL-FORMATS-I-0 OF PJDDS. 

+000001 @5 PJDDS-RECORD PIC X(4101). 

+000002* I-0 FORMAT: INPFMT FROM FILE PJDDS OF LIBRARY QNETUSER 
+000003* 

+000004 05 INPFMT REDEFINES PJDDS-RECORD. 

+000005 06 INPDATA PIC X(4096). 

+000006* I-0 FORMAT:DETACH FROM FILE PJDDS OF LIBRARY QNETUSER 
+000007* 

+000008* 05 DETACH REDEFINES PJDDS-RECORD. 

+000009* I-0 FORMAT: E0S FROM FILE PJDDS OF LIBRARY QNETUSER 
+000010* 

+000011* 05 EOS REDEFINES PJDDS-RECORD. 

+000012* I-0 FORMAT: INVITE FROM FILE PJDDS OF LIBRARY QNETUSER 
+000013* 

+000014* 05 INVITE REDEFINES PJDDS-RECORD. 

+000015* T-0 FORMAT: FAIL FROM FILE PJDDS OF LIBRARY QNETUSER 
+000016* 

+000017* 05 FAIL REDEFINES PJDDS-RECORD. 

+000018* I-0 FORMAT: IOFMT FROM FILE PJDDS OF LIBRARY QNETUSER 
+000019* 

+000020 05 IOFMT REDEFINES PJDDS-RECORD. 

+000021 06 IODATA PIC X(4096). 

+000022 06 OUTLEN PIC S$9(5). 


000590 FD QPRINT 
000600 LABEL RECORDS ARE OMITTED. 
000610 01 PRINTREC. 


000620 05 PRTNOTE PIC X(132). 
000640 WORKING-STORAGE SECTION. 

000660 77 STATUS-IND PIC X(2). 
000661 77 PIP PIC X(6). 
000662 01 MAJ-MIN. 

000663 05 MAJ PIC X(2). 
000664 05 MIN PIC X(2). 
000840 01 IO-FEEDBACK. 

000850 05 FILLER PIC X(149). 
000860 05 ACTUAL-LEN PIC 9(5) COMP-4. 
000870* 

001090 PROCEDURE DIVISION. 

001091 

001101* 


001450 START-PROGRAM-PARAGRAPH. 
QO 145 1 eee R KKK KK KEKE KKK KKK KKK KER EKER KKK RK KEK ERR ERE RRR KEK KKK EKER ER ERERER EK 
001452* OPEN ICF FILE AND PRINTER FILE * 
QO 1454 x eA KK KKK KEK ERK KKK KKK KKK KEKE RRR KKK KK KEK ERR EERE KER KEK KEKE ERE REE ERER ERE K 
001470 OPEN OUTPUT QPRINT. 

001471 OPEN I-0 ICFFILE. 

001480 MAIN-LOOP. 

001481 MOVE "WAITING FOR TRANSACTION" TO PRTNOTE. 

001482 WRITE PRINTREC. 

001483 «ex aA KK KK KEK KKK KKK KKK KKK KER EKER KK KKK KEK ERR ERR EKER KEK KEKE ERE REE ERERER EK 
001484* ACQUIRING THE REQUESTER PROGRAM DEVICE CAUSES THIS PRESTART * 
001485* JOB PROGRAM TO WAIT FOR A PROGRAM START REQUEST. * 
QO L486 x ee a KAKA KKK KKK KKK KKK EKER ER EKER KK KKK KEKE RRR ERK KERR KEKE RE REE ERER ERE K 
001590 ACQUIRE "REQDEVICE " FOR ICFFILE. 

001591 ee aK KAKA KEK EKK KKK KKK EKER ER ERE KKK KKK KEK ERR ERR KKK KKK KKK ERE RRR ERERER EK 
001592* IF THIS PRESTART JOB IS BEING ENDED WITH THE CONTROLLED OPTION, ~* 
001593* PERFORM END-OF-JOB PROCESSING AND EXIT. * 
QO 1594 x ee aK KK KK KEK EKK KKK KKK KKK KEKE RE RK KK KKK ERE RR EERE KEKE KK KEKE ERE REE ERER ERE K 
001600 IF MAJ-MIN = "8209" GO TO END-JOB. 

001610 MOVE "TRANSACTION ATTACHED" TO PRTNOTE. 

001620 WRITE PRINTREC. 

QO162 Lk xR ARK KAA KKA KKK EKER ERK ERE ER EK RRR ERR RRR ER RRR ER ERR ERE ERERER RE 
001622* CALL A CL PROGRAM TO USE SOME JOB ATTRIBUTES FROM THE PROGRAM * 
001624* START REQUEST USER PROFILE (CHGPJ). * 
QO 1625 x ee a KKK KK KEK KKK KKK KKK EKER EKER KKK K KKK KEKE ERR EERE KER KEK KKK REE RRR RRER ERE K 


001630 CALL "CLPGM". 
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(COMCRIR tee ee Se 


03/08/90 


001632* MOVE THE PIP DATA FROM THE PIP DATA AREA INTO IDENTIFIER PIP. * 03/08/90 
OO 16.34 x 2k a ae HH HK KKK KK KK IK KKK II KK KKK KKK IK KKK KIKI KK KKK KK KKK KIKI RIK IKK RK IK 03/08/90 
52 001635 ACCEPT PIP FROM PIP-PARM END-ACCEPT. 03/08/90 
OO LO 36k xR AA KKK AK KA AKER EKER RRR KER EKER EKER KR ER RR ER EKER RRR RRR EKER ERE ER EERE 03/07/90 
001637* MAIN BODY OF THE PROGRAM, THAT DOES THE COMMUNICATIONS 1/0 * 03/07/90 
001638* WITH THE SOURCE PROGRAM, SHOULD BE PLACED HERE. * 03/07/90 
OODLE 39k xR KKK K KAKA AKER E RRR RRR KER ERE KEKE RRR ER RR ER EK RRR EREREREREKEERERER RE 03/07/90 
OO L640 kx x KAKA AAR KA KR KKK RK RRR ERE R RK RRR KER RRR REE RRR ER ERE RE RERERERERR RR 03/07/90 
001641* WHEN THE MAIN BODY OF THE PROGRAM IS DONE PROCESSING, END * 03/07/90 
001642* THE COMMUNICATIONS SESSION AND LOOP BACK TO WAIT FOR THE NEXT * 03/07/90 
001643* PROGRAM START REQUEST TO COME IN. * 03/07/90 
OO 1644 kx xR KKK KARR KARR KEKE RRR RRR KER EKER ERR RRR RR RR ER ERE RRR ER ER ERE REREREREER ER 03/07/90 
53 001645 WRITE ICFREC FORMAT IS "EOS". 03/08/90 
54 001650 GO TO MAIN-LOOP. 03/07/90 
001660 END-JOB. 03/07/90 
55 001670 MOVE "PRESTART JOB BEING ENDED CONTROLLED" TO PRTNOTE. 03/07/90 
56 001680 WRITE PRINTREC. 03/07/90 
57 001690 CLOSE ICFFILE. 03/07/90 
58 001691 CLOSE QPRINT. 03/07/90 
59 001692 STOP RUN. 03/07/90 
001693 MAIN-EXIT. 03/07/90 
001700 EXIT. 03/07/90 


***e** END OF SOURCE 


* 21 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 000530 


Kk KKK 


Message . ... : No INPUT fields found for format DETACH. 


* 21 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 000530 


Message . .. . : No INPUT fields found for format EOS. 


* 21 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 000530 


Message . ... : No INPUT fields found for format INVITE. 


* 21 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 000530 


Message... . : No INPUT fields found for format FAIL. 
**** * END OF MESSAGES 


Message Summary 


Total Info(0-4) Warning(5-19) Error(20-29) 


4 0 4 ) 
Source records read. .......: 97 
Copy records read... ......: 22 
Copy members processed ......: 1 
Sequence errors ..........: @ 
Highest severity message issued. . : 10 


LBLO901 00 Program PJPGM created in library QNETUSER. 


Severe (30-39) 


kK kK KK 


Terminal (40-99) 
0 


kk kk OK END OF COMPILATION ** * * * 
Figure 8-2 (Part 3 of 3). COBOL/400 Coding for a Prestart Job Program 


System Considerations 


The specification of the PURGE parameter on the Create 
Class (CRTCLS) command for the routing entry used for 
communications can affect communications performance. 
The PURGE parameter controls the way the job’s operating 
resources are used when the job enters a wait state. If 
PURGE(*YES) is specified, the job’s operating resources are 
exchanged to auxiliary storage when the job enters a wait 
state. If PURGE(*NO) is specified, the job’s operating 
resources are not exchanged to auxiliary storage when the 
job enters a wait state. 


For communications, PURGE(*YES) is normally used for 
interactive applications because the application is normally 
waiting for a response from a work station operator. The 
wait delay time can be long enough for another job to do 
useful processing with the resources. PURGE(*NO) is 
normally used for batch applications when the AS/400 
system is sending data to or receiving data from another 
computer and the wait delay will be nominal. 
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For a complete description of these parameters or the 
CRTCLS command, see the Work Management book. 


Security Considerations 


The security provided on the AS/400 system is used to 
control who can use a communications device description 
and its associated commands. 


When a program issues an evoke to a remote AS/400 
system, you must ensure that proper security information is 
passed on the evoke request. See Chapter 6 and 
Chapter 7 for a discussion on how to specify the security 
information on the evoke. 


Although the security officer or service user has all object 
authority, explicit authorization to a target communications 
device description must be made. For example, if the secu- 
rity officer or service user has not been explicitly granted 
authority to the target device description, the program start 


request is rejected by the target system. This aspect of 
system security is consistent with the work station security 
implementation for the security officer and service user pro- 
files. Anyone with object management authority for a device 
description can grant authority for the device description to 
the security officer or service user. If the security officer or 
service user creates a device description, the security officer 
or service user (like anyone else who creates device 


descriptions) is explicitly authorized to the device description. 


When a communications device description is authorized to 
all users (*ALL), the security officer and service user are not 
included. This allows the security officer or service user to 
specify the device description from which the security officer 
or service functions can be performed. 


Refer to the appropriate communications programming book 
for more information about security considerations. 


File Considerations 


You should consider the following when deciding whether to 
use the system-supplied QICDMF file in your program: 


e System-supplied formats can be used either with the 
system-supplied QICDMF file or with an ICF file made 
using DDS processing keywords and the CRTICFF 
command. 


e User-defined formats cannot be added to the QICDMF 
file. Therefore, if your program uses the QICDMF file, it 
cannot use DDS processing keywords or externally 
described data. 


e If your program uses an ICF file created using DDS and 
the CRTICFF command, your program can use both the 


record formats defined as part of your ICF file and 
system-supplied formats. The high-level language you 
are using may have some restrictions on mixing system- 
supplied formats and user-defined formats. 


File Redirection 


You can override ICF files by using the override with file 
commands. 


When you change the file used in a program without 
changing the file type, the new file being used in the program 
is processed in the same manner as the original file. The 
format levels in the file must agree with the compiled 
program if level checking is done. If level checking is not 
done, the format of the changed-to file must be compatible 
with the compiled program or the results cannot be predicted. 


If you change from one file type to another, the file- 
dependent characteristics of the file are ignored and certain 
defaults are used. 


For a complete description of file redirection and the defaults 
used, see the Data Management book. 


Additional Considerations 


When using a particular communications type, you must be 
familiar with the requirements and restrictions unique to that 
communications type. For specific details, refer to the appro- 
priate programming book for the communications type you 
are using. 
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Chapter 9. ILE C Communications Applications 


Previous chapters in this book describe the functions pro- 
vided by ICF. This chapter introduces you to the ILE C inter- 
face for ICF and provides program examples. 


One program example is presented in this chapter, and both 
the source and target programs are provided. The example 
is a multiple-session inquiry application using one display file 
and four ICF sessions, and is written using user-defined 
formats (data description specifications or DDS). 


Not all programming considerations or techniques are illus- 
trated in the examples in this chapter. Review these exam- 
ples and the examples provided in the appropriate 
programming book before beginning application design and 
coding. 


Note: The examples in this chapter were written to the 
APPC communications type. Minor changes might be 
required if another communications type is used. 


Introduction to the ILE C Interface 


Before you write an ILE C communications application, you 
must understand the high-level language interface provided 
by ILE C programming language. 


The operations you use in the communications portion of 
your program are similar to work station operations. In the 
noncommunications portion of your program, you can use all 
noncommunications operations you normally use to process 
data that is sent or received between your program and the 
remote program. 


Figure 9-1 briefly introduces the ILE C functions you use in 
the communications portion of your program. 


Note: ILE C functions are case sensitive. 


Refer to the ILE C/400 Programmer's Guide for details on 
the syntax and function of each operation. 


Figure 9-1. ILE C Function 


ICF Operation ILE C Function Function 


Performs many of the ICF communications functions within a session 


Performs the specified function and then receives data from the remote system. 


Open fopen, _Ropen Opens the ICF file 

Acquire _Racquire Establishes a session 

Get-Attributes _Rdevatr Gets the attributes of a session 

Read fread, _Rreadn Receives data from a specific program device 
Read-from- _Rreadindv Receives data from any invited program device! 
invited- 

program- 

devices 

Write fwrite, _Rwrite 

Write/Read _Rwriterd 

Release _Rrelease Releases the session 

Close fclose, _Rclose Closes the ICF file 


1 The read-from-invited-program-devices operation could complete without data if the timer interval established with either the timer function 


or WAITRCD ends, or your job is ended (controlled). 


Multiple-Session Inquiry 


This example illustrates an interactive inquiry application that 
communicates with multiple ICF sessions. A source AS/400 
system program accepts inquiries from a display device and 
sends a request to one of four AS/400 systems. The source 
program communicates with the display device through a 
display file, and with the four remote systems through a 
single ICF file. 


The purpose of this example is to show multiple sessions 
from a single ICF file. The source program communicates 
with four sessions. From the viewpoint of each of the four 
target programs, there is only one session (with the 
requesting program device). Therefore, the target programs 
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do not require any unique logic to support the multiple- 
session source. 


Both the source program and the target program are 
described. The same target program is evoked in each of 
the four separate remote systems. Therefore, only one 
target program is shown in the programming example. 


Error Handling 


ILE C programming language provides an external variable, 
Maj_Min_rc, in the header file <stdio.h>, which contains the 
ICF major and minor codes after a read or write operation. 
The major and minor codes can also be obtained from the 
I/O feedback area. 


9-1 


A global variable, ERRNO, is defined in the header file Accessing the Feedback Areas 
<errno.h>. Two ERRNO values indicate that an exception 


has occurred: Your program can obtain a copy of the open feedback area 
EIOERROR by using the _Ropnfbk routine. The _Riofbk routine can be 

An I/O error has occurred that is not recoverable. used to obtain a copy of the I/O feedback area. 
EIORECERR 


A recoverable I/O error has occurred. 
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Transaction Flow of the Multiple-Session Inquiry: 
The program shown in Figure 9-2 is started from a display 
station, and both the display and the ICF file are opened. 
CIWS0O0 is the *REQUESTER device, acquired when the 
display file opens. CIWSO00 is acquired because 
DEV(*REQUESTER) was specified when the display file was 
created. Since the ICF file was created with 
ACQPGMDEV(*NONE), no ICF program devices are 
acquired during open processing. 


Display 


Station 


Remote AS/400 System 


Display File 


Open 


CIWS00 


Remote AS/400 System 


Open 
E ICFOO 


Program 


ICFO1 


ICF02 


ICFO3 


ICF File 


R te AS/400 System 
Local AS/400 System ce 


Remote AS/400 System 


Figure 9-2. Program Starts at Display Station 
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All other program devices are explicitly acquired by the 
program, as shown in Figure 9-3. 


Display 


Station 


Remote AS/400 System 


Display File 


Program ACQ 


CIWS00 


ICFOO 


Remote AS/400 System 


> ICF01 


ACQ 
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ICFO3 
ICF File 
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Figure 9-3. Program Devices Explicitly Acquired 
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All target programs are started with the evoke, as shown in 


Figure 9-4. 
Display 
Station 
Remote AS/400 System 
ICF Program Database 
>| . 
File File 
Display File 
CIWSOO 
Remote AS/400 System 
Write Evoke 
J 1 ICFOO 
rogram ‘ 
9 Write Evoke ICF Program Database 
ICFO1 id : F 
File File 
Write Evoke 
| ICFO02 
Write Evoke 
rr __*| IG F038 
ICF File 
Remote AS/400 System 
Local AS/400 System 
ICF Program Database 
>| 
File File 
Remote AS/400 System 
ICF Program Database 
>| 
File File 


Figure 9-4. Evoke Starts Target Programs 


7ooca 
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The source program uses a specific program device name. 
Each target program uses an ICF file with a program device 


name that is associated with the requesting program device. 


The target program’s only session is the one used to com- 
municate with the source program. The ICF file on the 
remote system must be opened by the ILE C language 


Display 


Station 


support using the open operation, and the requesting 
program device is acquired when the file is opened using the 
acquire operation. The main menu is written to the display 
station on the local system, and the program waits for a 
request from the display station, as shown in Figure 9-5. 
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File 
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File 
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Program 


ICFO1 


ICFO2 
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ICF File 


Local AS/400 System 
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Figure 9-5. Main Menu Written to Display Station 
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The source program sends an inquiry request to one of the 
remote systems based on the request made from the display 
station, as shown in Figure 9-6. 
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File File 
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Figure 9-6. Program Sends Inquiry Request to Remote System 


Chapter 9. ILE C Communications Applications 9-7 


The target program responds to the inquiry by sending a 
reply, as shown in Figure 9-7. 
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Figure 9-7. Target Program Sends a Reply 
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The program sends a detach request and ends the session 
when function key 1 is pressed (while the main inquiry menu 
is present), as shown in Figure 9-8. 
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Remote AS/400 System 


ICF Program Database 
File File 
Display File 
CIWS00 
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ICF Program Database 
|| File File 
Remote AS/400 System 
ICF Program Database 
File File 


oaadd 


Figure 9-8. Program Ends the Session 


Chapter 9. ILE C Communications Applications 


RSLS656-5 


9-9 


Source Program Multiple-Session Inquiry 


The following describes an ILE C source program multiple- 
session inquiry. 


Program Files: The ILE C multiple session source 
program uses the following files: 


CMNFIL 
An ICF file used to send records to and receive 
records from the target program. 


DSPFIL 
A display file used to enter requests that are to be 
sent to the target program. 


QSYSPRT 
A printer file used to print error messages resulting 
from communications errors. 


DDS Source: The DDS for the ICF file (CMNFIL) is illus- 
trated below. 


[XESS SOE IS OHHH IEEE IETS IE TET TI TI TI I TR IR TE 
Ax * 
Ax ICF FILE * 
Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 
Ax * 
[XESS SEIS SFE IGE IE TETAS IC TE TET I TI I I TR IR TE 
A INDARA 
R_ ITMRSP 

RECID(1 'I') 
RECITM 
ITEMNO 
DESC 
QTYLST 
QTYOH 
QTYoo 
QTYBO 
UNITQ 
PRO1 
PROS 
UFRT 
SLSTM 
SLSTY 
CSTTM 
CSTTY 
PRO 
Los 
FILL1 
DTLRSP 


w 


Boanhroroarnywsywwwwndar 


zp 
a 


RECID(1 'C') 
RECCUS 
CUSTNO 
DNAME 
DLSTOR 
DSLSTM 
DSPMO1 
DSPMo2 
DSPMO3 
DSTTYD 
IDEPT 
FILL2 
DETACH 


w w 
Qwhoecocoocadsar 
Seececcoeo 


zp 
a 


DETACH 
R EOS 
EOS 


zp 


EVKREQ 
EVOKE (CICFLIB/CTGTDMULCL) 
SECURITY(2 *USER 3 *USER) 


zp 


ITMREQ 

INVITE 
ITEMNO 6 0 
DTLREQ 


z 


INVITE 


PEST Srrrrrr rrr r rrr yryr Serre yr eS SSS SST SSrS Sr rr ySreryreryreryreye 


CUSTNO 6 0 


The DDS for the display file (DSPFIL) is illustrated below. 
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[inn Sasa rin S GSI IISA II ISN IGE INI IIIS IIIA 


Ax * 
Ax DISPLAY FILE * 
Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 
Ae * 


Dax E ESSE ISSCC SII IIIIEIIE CII TII I TIA TT RI I TIRE 
Ax BEGINNING MENU 
Ve CTreteereceeercaney 
A INDARA 
DSPSIZ(*DS3) 
CFO1(99) CFO2(98) CFO3(97) 
R CIMENU TEXT('MENU FOR INQUIRY') 
1 34' INQUIRY MENU' 
3 1'Select one of the following:' 
4 3'1. Item inquiry' 
5 3'2. Customer inquiry! 
11 1'Option:' 
OPTION IN I 11 9QVALUES('1' '2') 
19 5DFT('CMD KEY 1 - END ') 
R DTLMNU TEXT('CUSTOMER INQUIRY SCREEN 1') 
2 2DFT('ENTER CUSTOMER') 
CUSTNO 6N OI 2 20 
19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 


[ibn dsaconiinninninniaciniininiink 


Ax CUSTOMER INQUIRY SCREEN 


Vereeerereereere torr teeter tess 


A R DTLSCR TEXT('CUSTOMER INQUIRY SCR. #2') 

A 1 3DFT('CUST DPT LAST ORD & THIS + 
A $MTH1 &MTH2 $MTH3 THIS+ 
A YTD NAME') 

A CUSTN 6N suey 

A DEPT 3N0 2 9 

A DLSTR 6N 0 2 13 

A DSLSM ONO 222 

A DSPM1 ONO 2 32 

A DSPM2 ONO 2 42 

A DSPM3 ONO 2 52 

A DSTYD 11IN0 2 62 

A CNAME 30 274 

A 19 5DFT('CMD KEY 1 - END ') 

A 19 23DFT(' 2 - MAIN MENU ') 

Ax 


Vererreceeeterrrertereess 


Ax ITEM INQUIRY SCREEN 


Verereertererer torrets 


A R ITMMNU TEXT('ITEM INQUIRY SCREEN ONE') 
A 2 2DFT('ENTER ITEM NUMBER') 

A ITEMNO 6N OI 2 20 

A 19 5DFT('CMD KEY 1 - END ') 

A 19 23DFT(' 2 - MAIN MENU ') 


[Veter rerteet ete rereereess 
Ax ITEM DISPLAY 


Verereerteeererrcrtertess 


A R ITMSC2 TEXT('ITEM INQUIRY SCREEN TWO') OVE+ 
A RLAY 

A 4 2DFT('DESC-') 

A DSC 30 4 8 

A 5 2DFT('QUANTITY AVAILABLE') 
A QAVAIL 7N OQ 5 25 

A 6 11DFT('ON HAND') 

A QTYH 7N 0 6 25 

A 7 11DFT('ON ORDER') 

A Qryo 7N QO 7 25 

A 8 11DFT('BACK ORDER') 

A QTYB 7N 0 8 25 

A 9 2DFT('UNIT OF MEASURE') 
A UNT 2 9 30 

A 10 2DFT('PRICE PER UNIT') 
A PRI 7Y 2 10 24EDTCDE(3) 

A 11 8DFT('QUANTITY') 

A PR5 7Y © 11 25EDTCDE(3) 

A 12 8DFT('FREIGHT') 

A UFR 5Y 2 12 26EDTCDE(3) 

A 13 32DFT('MORE... ') 

A 19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 
A 19 40DFT(' 3 - ITEM MENU ') 


[itn dsacddinnninninnacniininiink 

Ax ITEM ADDITIONAL DISPLAY 

Vererereetere rrr rer reer errs. 

A R ITMSC3 TEXT('ITEM INQUIRY SCREEN 3 ') OVE+ 
RLAY 

2DFT('SALES MONTH') 

16EDTCDE (1) 

8DFT('Y-T-D') 


A 
A 
A SLSM oY 2 
A 
A 14EDTCDE (1) 


SLSY 11Y 2 


7 2DFT('COSTS MONTH') 
CSTM 9Y 2 7 16EDTCDE(1) 
8 8DFT('Y-T-D') 
CSTY 11Y 2. 8 14EDTCDE(1) 
9 2DFT('PROFIT PCT') 
PROFIT 5Y 2 9 22EDTCDE(1) 

10 2DFT('LOST SALES') 
LOSTS 11Y 2 10 14EDTCDE(1) 

19 5DFT('CMD KEY 1 - END ') 


19 23DFT(' 2 - MAIN MENU ') 


Prrrrrrrry 


[Vererreceeeterrrertertess 
Ax — TIMOUT SCREEN. 


[Veretrerteet ete rereertess 


A R TIMOUT TEXT('TIME OUT SCREEN') OVE+ 
A RLAY 

A 20 2DFT('REMOTE SYSTEM TIMED OUT. ENTER+ 
A 1 TO TRY AGAIN OR 2 TO END.') 

A TIMRSP 1 120 61 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(CICFLIB/CMNFIL) 
SRCMBR(CMNFIL) 
WAITRCD(30) 


SRCFILE(CICFLIB/QICFPUB) 
ACQPGMDEV(*NONE) MAXPGMDEV (4) 
TEXT("SOURCE ICF FILE FOR MULTIPLE 


SESSION PROGRAM") 


The commands needed to define the four program device 
entries are: 
OVRICFDEVE PGMDEV(ICFOO) RMTLOCNAME (CHICAGO) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICFO1) RMTLOCNAME (NEWYORK) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICFQ2) RMTLOCNAME(DETROIT) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICF03) RMTLOCNAME (MADISON) FMTSLT(*RECID) 


Program Explanation: The following explains the structure 
of the program example illustrated in Figure 9-9 on 

page 9-13. The ICF file used is defined by the user, and 
uses externally described data formats (DDS). The refer- 
ence numbers in the explanation below correspond to the 
numbers in the following program example. 


External file descriptions are included for the display 
file (DSPFIL). 


DSPFIL is the display file used to receive user’s 
requests and to report the information received based 
on the request. DSPFIL is implemented with the file- 
level keyword, INDARA, indicating a separate indicator 
area is used. 


External file descriptions are included for the ICF file 
(CMNFIL). 


CMNFIL is the ICF file used to send records to and 
receive records from each of the four target programs. 
CMNFIL is implemented with the file-level keyword, 
INDARA, indicating a separate indicator area is used. 


This structure is used to print the major or minor return 
code to the printer file QSYSPRT. Output to 
QSYSPRT is by record, so the filler field is used to 
blank out characters that may have been set by a pre- 
vious write to the printer file. See section Pj. 


The variables to be used globally by the program are 
defined here. The common and display/ICF feedback 
area pointers, the file pointers, and the display file sep- 
arate indicator area are defined. 


The routines, except the main routine, are prototyped 
so the compiler knows the type of value returned and 
the type of parameters passed, if any. 


The ICF and display files are opened for record 
input/output, and the printer file is opened for output. 
The ICF and display files are opened with the separate 
indicator area option specified. 


The separate indicator area is initialized and defined. 
The variable dsp_indic is a character array of size 99. 


The four program devices used by the program are 
explicitly acquired. 


The device for the work station is implicitly acquired 
when the DSPFIL file is opened. 


The program devices are specified before calling the 
evoke function four times to start transactions with the 
target program. 


The main menu is displayed, and the user is asked to 
type a 1 to process a request for item information, or a 
2 to process a request for customer information. 


If CMD 1 is pressed, indicator 99 is set by the system, 
a detach is sent to the remote program, the sessions 
are released, the files are closed, and the program 
ends. The separate indicator area array must be ini- 
tialized to character zeros before each input operation 
where indicators are checked. 


This function evokes the target program. If an error 
occurs, the program is ended. 


When the program start request is received at the 
remote system, CICFLIB is searched for 
CTGTDMULCL and that program then starts. 
CTGTDMULCL is a CL program that contains the fol- 
lowing statements: 


ADDLIBLE CICFLIB 
CALL CICFLIB/CTGTDMUL 


This procedure displays the item number inquiry 
display, and reads input from the user. If CMD 1 is 
pressed, the end-program flag is set, and the program 
ends on return to the main section of the program 
(main). If CMD 2 is pressed, control goes back to the 
main menu and a new main menu is displayed. 


If a valid number was entered, then a function to send 
the item number to the remote program is called and, if 
no errors were encountered, a function is called to 
issue a read to the ICF file to get the item information. 


This function selects the proper program device to use 
to send the item number to the target program and 
issues a write with an invite to the ICF file. ICFO1 is 
used for numbers less than 400000, ICF02 for 
numbers greater than 400000 and less than 700000, 
and ICFO3 for larger numbers. The number is copied 
from a display file structure to an ICF file structure, and 
then it is sent to the other program. The value 
returned from checking the return code (0 for 0000 
return code, 1 for all other return codes) is returned to 
the caller. 


This function gets called to receive item information 
from the target program after the user has specified a 
valid item number and that number has been sent to 
the target program. 


The read is a read-from-invited-devices operation. The 
item number was previously sent with an invite. 


A check is made to see if the remote system has timed 
out. (The wait time was specified on the CRTICFF 
command). A 0310 return code means a time-out has 
occurred after a read-from-invited-devices operation 
was issued. If a time-out did occur, a message is 
written to the display asking the user to try again (by 
typing 1) or to end the program (by typing 2). This 
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function gets called again if the user types 1. If 2 is 
entered, control returns to J and the end-program 
flag is set. 


If no data is received and the return code is 03XX, the 
request is sent again. 


If the data returns in the wrong format, an error indi- 
cation is returned to Fj. 


The target program may not have found the record cor- 
responding to the item number sent, in which case 
000000 would be returned from the target as the item 
number. If 000000 was received, then control goes to 
EJ to read another number from the display. 


The record received from the remote system is copied 
into the record used to print the information on the 
display, and then the information is written to the 
display using format ITMSC2. 


If CMD 1 is pressed from this display, the end-program 
flag is set causing the program to end on return to the 
main section of the program (main). If CMD 2 is 
pressed, the main menu is written to the display. If 
CMD 3 is pressed, the item inquiry menu is written to 
the display. By pressing the Enter key, the profit and 
loss figures are calculated and written to the work 
station. 


This procedure converts some of the values from char- 
acter strings to integers, so that profit and loss figures 
may be calculated. The integers must then be con- 
verted back to character strings to conform with the 
character data types in the ICF file. 


This procedure processes customer information 
requests, and is much like [. The customer inquiry 
display is displayed, indicators are checked, and func- 
tions are called to handle the sending and receiving of 
data. 


This function sends the customer number to the remote 
system with an invite. Program device ICFOO is used 
for processing customer information. 


ICF Programming V4R1 


rp 
i= 


iy) 
w 


This function receives information about a customer 
from the remote system and is structured like EJ. 
The major difference between this routine and the one 
in [QJ is that if the record format is valid, a check for 
a 000000 customer number received from the remote 
system is made before any other checks. If the target 
program cannot find the record corresponding to the 
item or customer number, the record ID field is set to 
‘l’, since the record ID does not exist. 


This function calls a procedure (section [Jj ) to access 
the display/ICF feedback area. It then checks for a 00 
major return code, which indicates that the previous I/O 
operation was successful. 


This function calls a procedure (section [—{j) to access 
the display/ICF feedback area. It then checks for a 03 
major return code, which indicates that data was not 
received. 


This function calls a procedure (section Ej) to access 
the display/ICF feedback area. It then checks for a 
0310 return code, which indicates that the timer interval 
has ended. 


This procedure issues a detach function to each of the 
program devices that were acquired, indicating to the 
remote systems that this program is about to end. 


This procedure releases the sessions that were 
acquired, and then calls another procedure to close the 
files. 


This procedure closes the ICF, display, and printer 
files. 


This procedure retrieves the return code to be printed 
from the display/ICF feedback area, and then prints the 
appropriate message to the printer file. 


This procedure accesses the common I/O feedback 
area and the display/ICF feedback area. The pointers 
must be reset after each I/O operation, after which 
information is to be retrieved from the feedback areas. 
Therefore, this procedure is called before any checking 
of return codes is done. 


Program name 
Library name 
Source file 
Library name 
Source member name . 
Text Description 


CSRCDMUL 
CICFLIB 

QICFPUB 
CICFLIB 

CSRCDMUL 


x kK KK * 


PROLOG 


Source C program for ICF Prog 


xk KKK 


Compiler options ....... :  ¥*SQURCE *NOXREF *NOSHOWUSR *NOSHOWSYS *NOSHOWSKP *NOEXPMAC -*NOAGR 
*NOPPONLY »*NODEBUG *GEN *NOSECLVL = *PRINT *LOGMSG 

Language level options ....: *EXTENDED 

Source margins: 
Left margins snk aa we ee 1 
Right:margin: 4%. a-a0 ee 32767 

Sequence columns: 
be ftoCol umn 6-22) et: toh dents kd 
Right. Column: =. 3. 6 ee 

Define name... .....2..3 

Generation options ......: *NOLIST *NOXREF *GEN *NOATR *NODUMP *NOOPTIMIZE *NOALWBND 

*NOANNO 

Pravint: TAT@% ate a tee od Ge Gi IQSYSPRT. 
Library name ........32 *LIBL 

Message flagging level ....: 0 

Compiler message: 
Message limit. .......: *NOMAX 
Message limit severity 30 

Replace program object ....: ¥*YES 

User profile S44 s eee De *USER 

AUTHOPIEY wi Se See Gee ee *CHANGE 

Target Release ........ :  *CURRENT 

bast ichanges) 6% eerie ae wt 90/08/20 18:18:16 

Source description ......: Source C program for ICF Prog 

Comparten’ x gc he eee HE IBM ILE C/400 Compiler 

kK kK KKK SOURCE Kk KKK 
Line STMT SEQNBR = INCNO 
Kec GPsmaalad oetated. Lawde tence wehes te Ae ti Pisin cD Ras T aol Oe este ae ater Rae Bie sates sedwieree 

1 #pragma mapinc("dspf", "cicflib/dspfil(*all)", "both", "p z") 1 
2 #include "dspf" 2 
3 #pragma mapinc("icff/itmrsp", "cicflib/cmnfil(itmrsp)", "input", "p z") 3 
4 #pragma mapinc("icff/dtIrsp", "cicflib/cmnfil(dtirsp)", "input", "p z") 4 
5 #pragma mapinc("icff/itmreq", "cicflib/cmnfil(itmreq)", "output", "p z" 5 
6 #pragma mapinc("icff/dtlreq", "cicflib/cmnfil(dtlreq)", "output", "p z" 6 
7 #include “icff/itmrsp" 7 
8 #include “icff/dtIrsp" 8 
9 #include “icff/itmreq" 9 
10 #include "icff/dtlreq" 0 
11 [Brien teense enn cn conn ent anh eceesiweredans soba cakedwetenscecetaneheseas */ 1 
12 /* This program assigns four sessions as follows: */ 2 
13 /* 'ICFOO' to inquire about a customer account before an order is */ 3 
14 /* processed. */ 4 
15 /* 'ICFO1' to inquire about the inventory status of an item being */ 5 
16 /* ordered (item 000001 thru 399999). */ 6 
17 /* 'ICFO2' to inquire about the inventory status of an item being */ 7 
18 /* ordered (item 400000 thru 699999). */ 8 
19 /* 'ICFO3' to inquire about the inventory status of an item being */ 9 
20 /* ordered (item 700000 thru 999999). */ 20 
21 /* A display device is used to enter the request (using a customer */ 21 
22 /* and an item menu) that is sent to the remote system. */ 22 
23 [k-------------------------------- +++ --- === == +--+ 2-2 = + */ 23 


Figure 9-9 (Part 1 of 12). Source Program Example — CSRCDMUL (User-Defined Formats) 
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Figure 9-9 (Part 2 of 12). Source Program Example — CSRCDMUL (User-Defined Formats) 
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#define ON 1 
#define OFF 0 
#define ION '1' 
#define IOFF '0' 
#define ERROR 1 
#define NOERROR 0 
#define NORM_END 1 
#define RCD_ERR 2 
#define ERR_END 3 
#include <stdio.h> 
#include <recio.h> 
#include <stdlib.h> 
#include <stddef.h> 
#include <string.h> 
#include <xxfdbk.h> 


#include <xxcvt.h> 


ICFLIB_DSPFIL, 
ICFLIB_DSPFIL 


ICFLIB_DSPFIL 
ICFLIB_DSPFIL 


c 

c 

c 
CICFLIB_DSPFIL_ 
c 

c 
CICFLIB_DSPFIL 


/* 
/* 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


/* 


CIMENU_both_t cimenu_dsp_i; 
_DTLMNU_both_t dtImnu_dsp_i; 
ICFLIB_DSPFIL_DTLSCR_both_t dtlscr_dsp_o; 
ITMMNU_both_t itmmnu_dsp_i; 
ITMSC2_both_t itmsc2_dsp_o; 
ITMSC3_both_t itmsc3_dsp_o; 

TIMOUT_both_t timout_dsp_i_o; 


Indicator is set on */ 
Error occurred */ 


Print normal end message */ 
Print wrong record error msg */ 
Print generic error message */ 
Standard I/0 header */ 

Record I/0 header */ 

General utilities */ 

Standard definitions */ 

String handling utilities */ 
Feedback area structures */ 


EPM conversion routines */ 


CICFLIB_CMNFIL_ITMRSP_i_t itmrsp_icf_i; 

CICFLIB_CMNFIL_DTLRSP_i_t dtlrsp_icf_i; 

CICFLIB_CMNFIL_ITMREQ_o t itmreq_icf_o; 

CICFLIB_CMNFIL_DTLREQ_o t dtlreq_icf_o; 

[ee eete noses sn Hest ese ese ses sees re see oe se eee eee see ee eee este ee ees */ 
/* Define structure used to write to the print file. */ 
[ee Bose ee boson sesh ele ace eee See esos ese csee see cee csae tess es */ 
struct { 


char major??(2??); 
char minor??(2??); 


char filler??(32??); /* Used for padding with blanks */ 
} print_rec; 
4 
(jeesoehee tes tacacee Sete Ress este es oee bes esos eo ee sant esses */ 
/* Declare global variables */ 
(ee sesesedewes Hesse ee se ete este we see eee ese eee ee eee see ese te eels */ 
_RFILE *icffptr; /* Ptr to ICF file */ 
_RFILE *dspfptr; /* Ptr to display file */ 
_RFILE *prtfptr; /* Ptr to print file */ 
_XXIOFB_T *comm_fdbk; /* Ptr to common I/0 feedback */ 
“XXIOFB_DSP_ICF_T *dsp_icf_fdbk; /* Ptr to dsp/ICF I/0 feedback */ 
char dsp_indic??(99??); /* Display separate indic area */ 


int evoke_target (void); 

void process_item_req(int *); 
int send_item_req(void) ; 

int rec_item_info(int *); 
void calc_profit_loss(void); 
void process _cust_req(int *); 
int send_cust_req(void) ; 

int rec_cust_info(int *); 

int pos_ret_code(void) ; 

int pos_ret_code(void); 

int check_no_data(void) ; 

int check_timeout (void) ; 

void detach(void) ; 

void end_job(void); 

void close_files(void); 

void print_msg(int); 

void get_access_to_fb(void); 
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main() 95 
{ 96 
int end_pgm_flag = OFF; /* Signals program end request */ 97 
98 

| hatatetatatatatatetatatatetatatatatatatetatatatetatattatetatatetatatatatataietatatatatetatatatataiatatetaatatatatatate */ 99 
/* Open ICF, display, and printer files. If an error occurs,*/ 00 
/* the program will end. */ 01 
[*----------------------------- 2-222-222-2222 2-22-22 -------- */ 02 
03 

if ((icffptr = _Ropen("CICFLIB/CMNFIL", “art indicators=y riofb=y")) 04 
== NULL) 05 

exit (ERROR) ; 06 

if ((dspfptr = Ropen("CICFLIB/DSPFIL", “art indicators=y riofb=y")) 07 
== NULL) { 08 

_Rclose(icffptr); 09 
exit (ERROR) ; 0 

} 1 
if ((prtfptr = _Ropen("CICFLIB/QSYSPRT", "wr")) == NULL) { 2 
_Rclose(icffptr); 3 
_Rclose(dspfptr); 4 
exit (ERROR) ; 5 

} 6 
7 
[kaon nnn nnn nn nnn nnn nnn nnn nnn nn nnn nnn enn nnn e eee */ 8 
/* Set up separate indicator area for the display file. */ 9 
[*----------------------------------------------------------- */ 20 
21 

memset(dsp_indic, IOFF, 99); 22 
_Rindara(dspfptr, dsp_indic); 23 
8 | 24 
[ko -------------------- 2-2-2222 2-2-2222 o-oo 2-2-2222 ---- */ 25 
/* Explicitly acquire four sessions. If an error occurs on */ 26 
/* any of the acquire operations then the ICF and display */ 27 
/* files will be closed, an error message will be printed, */ 28 
/* and the program will end. */ 29 
[kann nnn nnn nn nnn nnn nn nnn nnn nnn nnn nnn nn enn nnn e eee */ 30 
31 

_Racquire(icffptr, "ICFOO"); 32 
if (pos_ret_code() == ERROR) { 33 
close_files(); 34 
exit (ERROR) ; 35 

} 36 
_Racquire(icffptr, "ICFO1"); 37 
if (pos_ret_code() == ERROR) { 38 
close _files(); 39 
exit (ERROR) ; 40 

} 41 
_Racquire(icffptr, "ICFO2"); 42 
if (pos_ret_code() == ERROR) { 43 
close _files(); 44 
exit (ERROR) ; 45 

} 46 
_Racquire(icffptr, "ICF03"); 47 
if (pos_ret_code() == ERROR) { 48 
close _files(); 49 

exit (ERROR) ; 50 

} 51 
19 | 52 
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/* Evoke the target four times. If an error occurs on any of */ 


/* the evoke operations then detach, release, and close */ 
/* operations will be issued, an error message printed, and */ 
/* the program will end. */ 
[keno n nn nnn nnn n-ne ne nnn nen nen ee eee eee */ 

28 _Rpgmdev(icffptr, "ICFOO"); 

29 if (evoke _target() == ERROR) 

30 exit (ERROR) ; 

31 _Rpgmdev(icffptr, "ICFO1"); 

32 if (evoke_target() == ERROR) 

33 exit (ERROR) ; 

34 _Rpgmdev(icffptr, "ICFO2"); 

35 if (evoke _target() == ERROR) 

36 exit (ERROR) ; 

37 _Rpgmdev(icffptr, "ICFO3") 

38 if (evoke _target() == ERROR) 

39 exit (ERROR) ; 
[keno n nn nnn nnn ne en nen nen een een ee ee eee */ 
/* Put out the main menu to the display, and depending on */ 


/* the input, either request item information or customer */ 
/* information from remote system. If CMD 1 (indicator 99) */ 
/* is pressed on any screen, the program ends. If the user */ 
/* picks option 1, an item inquiry is processed, and if the */ 
/* user picks option 2 a customer inquiry is processed. If */ 
/* CMD 1 wasn't pressed, nor option 1 or 2, then the input */ 


/* is invalid. */ 
[wenn nnn nnn n 2-2 oe en nen nn een nen ee eee eee */ 
40 while (end_pgm_flag == OFF) { 
41 _Rformat(dspfptr, "CIMENU") ; 
42 _Rwrite(dspfptr, NULL, 0); 
43 memset (dsp_indic, IOFF, 99); 
44 _Rreadn(dspfptr, &cimenu_dsp_i, sizeof(cimenu_dsp_i), _ DFT); 
45 if (dsp_indic??(98??) == IOFF) { 
46 if (cimenu_dsp_i.OPTION == '1') 
47 process_item_req(&end_pgm_flag) ; 
else 
48 if (cimenu_dsp_i.OPTION == '2') 
49 process_cust_req(&end_pgm_flag) ; 
} 
else 
50 print_msg(NORM_END) ; 
51 end_pgm_flag = ON; 
} 
} 
52 detach(); 
53 end_job(); 
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/* Evoke the Target Program 
/* Evoke the target program. If an error occurs then a detach will be 
/* sent, a release will be issued, and the ICF, display, and printer 
/* files will be closed. 
PeRwnosaesenseasesssenns sh scesesecsussu cede sssesesedssuspcSss-sosese~ss+ 
evoke_target() 
{ 
_Rformat(icffptr, "EVKREQ"); 
“Rwrite(icffptr, NULL, 0); 
if (pos_ret_code() == ERROR) { 
print_msg(ERR_END) ; 
detach(); 
end_job(); 
return (ERROR) ; 
} 
return (NOERROR) ; 
} 
[Rinoeasercseissencis-schsssscsecensse sce sessncs ese dSsustctss-sosesees-+ 
/* Process Item Request Screen 
/* This routine puts out the item request screen and reads the input 
/* from the user. CMD 1 (end job), CMD 2 (go to main menu), and CMD 3 
/* (reenter item number) are checked. Routines to send a valid item 
/* number and to receive item information are called. 
[#ssennectescseaese non ne nb seen esate ono e sean tense eee seceeesn sents 
void process_item_req(int *end_pgm flag) 
{ 
_Rformat(dspfptr, "ITMMNU") ; 
_Rwrite(dspfptr, NULL, 0); 
memset(dsp_indic, IOFF, 99); 
_Rreadn(dspfptr, &itmmnu_dsp_i, sizeof(itmmnu_dsp_i), _ DFT); 
if (dsp_indic??(98??) == ION) { /* CMD 1, indic 99 */ 
print_msg(NORM_END) ; 
xend_pgm_flag = ON; 
} 
else 
if (dsp_indic??(97??) == IOFF) /* CMD 2, indic 98 */ 
if (send_item_req() == NOERROR) { 
if (rec_item_info(end_pgm flag) == ERROR) { 
print_msg(ERR_END) ; 
xend_pgm_flag = ON; 
} 
} 
else { 
print_msg(ERR_END) ; 
*end_pgm_flag = ON; 
} 
} 
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/* Send Item Request */ 
/* This routine sends the item number entered to the appropriate target */ 
/* program based on the range of the number. */ 
[Beene nnn nn nnn nn nnn nn nn nn nn nnn nn enn en nnn ene nn enn en ne nee eee */ 
send_item_req() 
{ 

1 _Rformat(icffptr, "ITMREQ"); 

2 if (strncmp(itmmnu_dsp_i.ITEMNO, "399999", 6) != 1) 

3 _Rpgmdev(icffptr, "ICFO1"); 

else 
4 if (strncmp(itmmnu_dsp_i.ITEMNO, "699999", 6) != 1) 
5 _Rpgmdev(icffptr, "ICF02"); 
else 


6 _Rpgmdev(icffptr, "ICFO3") ; 

7 strncpy(itmreq_icf_o.ITEMNO, itmmnu_dsp_i.ITEMNO, 6); 

8 _Rwrite(icffptr, &itmreq_icf_o, sizeof(itmreq_icf_o)); 

9 return(pos_ret_code()); 
} 
[ke sowene cosas sesh eet eee ee nec sone sess en eases eset see sles */ 
/* Receive Item Information */ 
/* The item information is read from the remote system. A check is */ 


/* made for three conditions following the read: 1) The remote system */ 
/* timed out, 2) no data was received, and 3) data was returned in an */ 
/* unexpected format. */ 
/* If the remote system times out (maj/min 0310), a message is written */ 
/* to the screen asking to try again (enter 1) or to end the program */ 


/* (enter 2). */ 
/* If no data is received (major 03) the request is sent again to the */ 
/* remote system. */ 
/* If the record returns with the wrong record format, the program will */ 
/* end on error. */ 
/* If CMD 1 (in99) is pressed, the end program flag is set causing the */ 
/* program to end upon return to main. If CMD 2 (in98) is pressed, */ 
/* the main menu is written to the screen. If CMD 3 (in97) is pressed, */ 
/* the item inquiry menu is written to the screen. */ 
/* If the remote program didn't find the item, and the item number */ 
/* "Q00000" was returned, then the item request screen is displayed. */ 
Jie coanesccsontes secacenseccseenciaccel ese sessechas asses een scssoshcseece */ 
rec_item_info(int *end_pgm_flag) 

{ 


1 _Rreadindv(icffptr, &itmrsp_icf_i, sizeof(itmrsp_icf_i), _ DFT); 

3 if (check_timeout() == 0) { 

4 _Rformat(dspfptr, "TIMOUT") ; 

5 _Rwrite(dspfptr, NULL, 0); 

6 _Rreadn(dspfptr, &timout_dsp_i_o, sizeof(timout_dsp_i_o), _ DFT); 
7 if (timout_dsp_i_o.TIMRSP == '1') 

8 return(rec_item_info(end_pgm_flag)); 


else 
9 if (timout_dsp_i_o.TIMRSP == '2') { 
10 print_msg(NORM_END) ; 
11 *end_pgm_flag = ON; 
12 return (NOERROR) ; 
} 


} 
9-9 (Part 6 of 12). Source Program Example — CSRCDMUL (User-Defined Formats) 


ICF Programming V4R1 


BRR RE R 


9-9 (Part 7 of 12). Source Program Example — CSRCDMUL (User-Defined Formats) 


else 
if (check_no_data() == 0) { 
_Rformat(icffptr, "ITMREQ"); 
_Rwrite(icffptr, &itmreq_icf_o, sizeof(itmreq_icf_o)); 
return(pos_ret_code()); 


/* No data received */ 


} 
else { /* Check for valid record fmt */ 

comm_fdbk = _Riofbk(icffptr); 

if (strncmp(comm_fdbk->rec_format, "ITMRSP ", 10) != 0) { 

print_msg(RCD_ERR) ; 
return(ERROR) ; 

} 

} 
if (strncmp(itmrsp_icf_i.ITEMNO, "000000", 6) != 1) /* Item not found */ 
process_item_req(end_pgm_flag); 
else { 

strncpy(itmsc2_dsp_o.DSC, itmrsp_icf_i.DESC, 30); 
strncpy(itmsc2_dsp_o.QAVAIL, itmrsp_icf_i.QTYLST, 7); 
strncpy(itmsc2_dsp_o.QTYO, itmrsp_icf_i.QTYOO, 7); 
strncpy(itmsc2_dsp_o.QTYH, itmrsp_icf_i.QTYOH, 7); 
strncpy(itmsc2_dsp_o.QTYB, itmrsp_icf_i.QTYBO, 7); 
strncpy(itmsc2_dsp_o.UNT, itmrsp_icf_i.UNITQ, 2); 
strncpy(itmsc2_dsp_o.PR1, itmrsp_icf_i.PRO1, 7); 
strncpy(itmsc2_dsp_o.PR5, itmrsp_icf_i.PRO5, 7); 
strncpy(itmsc2_dsp_o.UFR, itmrsp_icf_i.UFRT, 5); 
_Rformat(dspfptr, "ITMSC2"); /* Display item screen 2 */ 
_Rwrite(dspfptr, &itmsc2_dsp_o, sizeof(itmsc2_dsp_o)); 
memset (dsp_indic, IOFF, 99); 
_Rreadn(dspfptr, NULL, 0, DFT); 
if (dsp_indic??(98??) == ION) { /* CMD 1, indic 99 */ 

print_msg(NORM_END) ; 

*end_pgm_flag = ON; 


} 
else 
if (dsp_indic??(96??) == ION) /* CMD 3, indic 97 */ 
process_item_req(end_pgm_flag); 
else 
if (dsp_indic??(972?) == IOFF) { 
calc_profit_loss(); 
_Rformat(dspfptr, "ITMSC3"); /* Display screen 3 */ 
_Rwrite(dspfptr, &itmsc3_dsp_o, sizeof(itmsc3_dsp_o)); 
memset (dsp_indic, IOFF, 99); 
_Rreadn(dspfptr, NULL, 0, DFT); 
} 


} 
return (NOERROR) ; 
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[ee seee see so- castes see nes eee see eee ee sane ete e es oboe eee es eee ees */ 
/* Calculate Profit/Loss */ 
/* This routine calculates profit and loss figures and displays them */ 
/* on screen two of the item. */ 
[Beene nnn nnn nn nnn nnn nn nn nn nn nnn nnn nn en nn nn enn enn ee ne nee */ 
void calc_profit_loss() 
{ 
long qtylst_l; 
double slstm_d, csttm_d; 
double pr01_d, losts_d, profit_d; 
1 csttm_d = QXXZTOD(itmrsp_icf_i.CSTTM, 9, 2); 
2 qtylst_1 = QXXZTOI(itmrsp_icf_i.QTYLST, 7, 0); 
3 prOl_d = QXXZTOD(itmrsp_icf_i.PRO1, 7, 2); 
4 slstm_d = QXXZTOD(itmrsp_icf_i.SLSTM, 9, 2); 
5 profit_d = csttm_d - slstm_d; 
6 profit_d *= 100; 
7 if (slstm_d > 0) 
8 profit_d /= slstm_d; 
9 losts_d = qtylst_] * prOl_d; 
10 strncpy(itmsc3_dsp_o.SLSM, itmrsp_icf_i.SLSTM, 9); 
11 strncpy(itmsc3_dsp_o.SLSY, itmrsp_icf_i.SLSTY, 11); 
12 strncpy(itmsc3_dsp_o.CSTM, itmrsp_icf_i.CSTTM, 9); 
13 strncpy(itmsc3_dsp_o.CSTY, itmrsp_icf_i.CSTTY, 11); 
14 QXXDTOZ(itmsc3_dsp_o.LOSTS, 11, 2, losts_d); 
15 QXXDTOZ(itmsc3_dsp_o.PROFIT, 5, 2, profit_d); 
} 
[ee seto ee so seb sesh sete ee ee scene co soe cscs een eee saat see sb oes */ 
/* Process Customer Request */ 
/* This routine puts out the customer request screen and reads the */ 
/* input from the user. CMD 1 (end job) and CMD 2 (go to main menu) */ 
/* are checked. Routines to send the customer number and to receive */ 
/* customer information are called. */ 
[Beene nnn nnn nn nn nnn nnn nn nn nnn nnn nn en nnn nn enn en een ene eee */ 
void process _cust_req(int *end_pgm flag) 
{ 
1 _Rformat(dspfptr, "DTLMNU"); 
2 _Rwrite(dspfptr, NULL, 0); 
3 memset(dsp_indic, IOFF, 99); 
4 _Rreadn(dspfptr, &dtlmnu_dsp_i, sizeof(dtImnu_dsp_i), _ DFT); 
5 if (dsp_indic??(98??) == ION) { /* CMD 1, indic 99 */ 
6 print_msg(NORM_END) ; 
7 xend_pgm_flag = ON; 
else 
8 if (dsp_indic??(97??) == IOFF) /* CMD 2, indic 98 */ 
9 if (send_cust_req() == NOERROR) { 
10 if (rec_cust_info(end_pgm_flag) == ERROR) { 
11 print_msg(ERR_END) ; 
12 xend_pgm_flag = ON; 
} 
} 
else { 
13 print_msg(ERR_END) ; 
14 *end_pgm_flag = ON; 
} 
} 
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[eesoreisew eee ste eb tes ee scat Se ee ee eee eee e's Sesh eee */ 
/* Send Customer Request */ 
/* This routine sends the customer number entered by the user to the */ 
/* remote program. The number has already been read in. */ 
[Been nnn nnn nn nn nnn nnn nnn nn nnn nn en en nnn en nnn enn en nen nee eee */ 
send_cust_req() 
{ 
1 strncpy(dtlreq_icf_o.CUSTNO, dtlmnu_dsp_i.CUSTNO, 6); 
2 _Rformat(icffptr, "DTLREQ"); 
3 _Rpgmdev(icffptr, "ICFOO"); 
4 _Rwrite(icffptr, &dtlreq_icf_o, sizeof(dtlreq_icf_o)); 
5 return(pos_ret_code()); 
} 
[Re Socisiew eee shee eh tee eet sce at See oe see eee eee ess Se eteee eee */ 
/* Receive Customer Information */ 
/* This routine attempts to receive customer information from the */ 
/* target program. A check is made for the following three conditions */ 
/* following the read operation: 1) The remote system timed out, 2) no */ 
/* data was received, and 3) data returned in an unexpected format. */ 
/* If the remote system times out (maj/min 0310), a message is written */ 
/* to the screen asking user to try again (enter 1) or to end the */ 
/* program (enter 2). */ 
/* If no data is received (major 03) the request is sent again to the */ 
/* remote system. */ 
/* If the record returns with the wrong record format, the program will */ 
/* end on error. */ 
/* If the remote program didn't find the customer, and the item number */ 
/* "000000" was returned, the main menu is displayed. */ 
Jka conde cece sees seal seee Sse snee ns si esos ee ses ete ese e pe sscceesnsiceee */ 
rec_cust_info(int *end_pgm_flag) 
{ 
1 _Rreadindv(icffptr, &dtIrsp_icf_i, sizeof(dtIrsp_icf_i), _ DFT); 
3 if (check_timeout() == 0) { 
4 _Rformat(dspfptr, "TIMOUT"); 
5 _Rwrite(dspfptr, NULL, 0); 
6 _Rreadn(dspfptr, &timout_dsp_i_o, sizeof(timout_dsp_i_o), _ DFT); 
7 if (timout_dsp_i_o.TIMRSP == '1') 
8 return(rec_cust_info(end_pgm_flag)); 
else 
9 if (timout_dsp_i_o.TIMRSP == '2') { 
0 print_msg(NORM_END) ; 
1 *end_pgm_flag = ON; 
2 return (NOERROR) ; 
} 
} 
else 
3 if (check_no_data() == 0) { /* No data received «/ 
4 _Rformat(icffptr, "DTLREQ"); 
5 _Rwrite(icffptr, &dtlreq_icf_o, sizeof(dtlreq_icf_o)); 
6 return(pos_ret_code()); 
} 
else { /* Was item found ? */ 
7 if (strncmp(dtIrsp_icf_i.CUSTNO, "000000", 6) != 1) 
8 return (NOERROR) ; 
else { /* Check record format «/ 
9 comm_fdbk = _Riofbk(icffptr) ; 
20 if (strncmp(comm_fdbk->rec_format, "DTLRSP ", 10) != 0) { 
21 print_msg(RCD_ERR) ; 
22 return (ERROR) ; 
} 
} 
} 
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497 23 strncpy(dtlscr_dsp_o.CUSTN, dtlrsp_icf_i.CUSTNO, 6); 

498 24 strncpy(dtlscr_dsp_o.CNAME, dtlrsp_icf_i.DNAME, 30); 

499 25 strncpy(dtlscr_dsp_o.DLSTR, dtlrsp_icf_i.DLSTOR, 6); 

500 26 strncpy(dtlscr_dsp_o.DSLSM, dtlrsp_icf_i.DSLSTM, 9); 

501 2h strncpy(dtlscr_dsp_o.DSPM1, dtlrsp_icf_i.DSPMQ1, 9); 

502 28 strncpy(dtlscr_dsp_o.DSPM2, dtlrsp_icf_i.DSPMQ2, 9); 

503 29 strncpy(dtlscr_dsp_o.DSTYD, dtlrsp_icf_i.DSTTYD, 11); 

504 30 strncpy(dtlscr_dsp_o.DEPT, dtlrsp_icf_i.IDEPT, 3); 

505 31 _Rformat(dspfptr, "DTLSCR"); /* Display customer info */ 
506 32 _Rwrite(dspfptr, &dtlscr_dsp_o, sizeof(dtlscr_dsp_o)); 

507 33 memset(dsp_indic, IOFF, 99); 

508 34 _Rreadn(dspfptr, NULL, 0, _ DFT); 

50935 if (dsp_indic??(98??) == ION) { 

510 36 print_msg(NORM_END) ; 

511 37 xend_pgm_flag = ON; 

512 

513 38 return (NOERROR) ; 

514 } 

515 

516 

517 [tan n nn nn nnn nn nnn nn nnn nnn nnn nnn nn nnn nnn nnn nnn nnn nn nnn nnn nnn nnn nnn nee */ 
518 /* Check For Successful Operation */ 
519 /* If the major return code is 00 the last operation attempted was */ 
520 /* successful, otherwise an error occurred. */ 
521 [k------------------------------------------ == === +--+ == +--+ */ 
522 

523 pos_ret_code() 

524 { 

525 1 get_access_to_fb(); 

526 2 if (strncmp(dsp_icf_fdbk->major_ret_code, "00", 2) == @) 

527 3 return (NOERROR) ; 

528 else 

529 4 return (ERROR) ; 

530 } 

531 

532 

533 [tan n nnn nnn nnn nnn nn nen nnn nnn nnn nn nnn nn nnn nnn nnn nn nnn nn nnn nn nnn nn nee */ 
534 /* Check for No Data Received x/ 
535 /* If the major return code is 03 then no data was received on an input */ 
536 /* operation. */ 
537 | bicetatatatatatatatatatatatatatatatatatatattatatatatatatatatetatatatatetatatetatetatatetatatatatatatatatattatattataaattaataatatatel x/ 
538 

539 check_no_data() 

540 { 

541 1 get_access_to_fb(); 

542 2 if (strncmp(dsp_icf_fdbk->major_ret_code, "03", 2) == @) 

543 3 return (0) ; 

544 else 

545 4 return(1); 

546 } 

547 

548 

549 [kann n nnn nnn nn nnn nn nn nnn nnn nnn nnn nnn nnn nn nn nnn nn nnn nnn nnn nnn nn nee */ 
550 /* Check for Timeout x/ 
551 /* If the major/minor return code is 0310, then a timeout occurred when «/ 
552 /* reading from an invited program device. Return 1 if timeout occurred*/ 
553 /* otherwise return 0. x/ 
554 | bicetatetatatatatatatatetatatatatatatatatattatatatatatatatatatatatadaatatattaietatatetaatataataatatattaatataataataaatadatatated */ 
555 

556 check_timeout () 

557 { 

558 1 get_access_to_fb(); 

559 if ((strncmp(dsp_icf_fdbk->major_ret_code, "03", 2) == 0) 8& 

560 2 (strncmp(dsp_icf_fdbk->minor_ret_code, "10", 2) == 0)) 

561 3 return (0) ; 

562 else 

563 4 return(1); 

564 } 

565 

566 
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567 [Bonne nnn nnn nn nnn nnn nnn nn nn nnn nnn nnn nnn nnn nnn nnn nn nnn nen nnn n nnn n ee */ 567 
568 /* Issue Detach */ 568 
569 /* A detach is sent to each program device to end the transaction with */ 569 
570 /* the remote system. */ 570 
571 | eee res */ 571 
572 22 | 572 
573 void detach() 573 
574 { 574 
575 1 _Rformat(icffptr, "DETACH"); 575 
576 2 “Rpgmdev(icffptr, "ICFO0"); 576 
577 3 “Rwrite(icffptr, NULL, 0); 577 
578 4 “Rpgmdev(icffptr, "ICFO1"); 578 
579 5 _Rwrite(icffptr, NULL, 0); 579 
580 6 “Rpgmdev(icffptr, "ICFO2"); 580 
581 7 “Rwrite(icffptr, NULL, 0); 581 
582 8 “Rpgmdev(icffptr, "ICFO3"); 582 
583 9 “Rwrite(icffptr, NULL, 0); 583 
584 } 584 
585 585 
586 586 
587 [anne nnn nnn nn nnn nnn nnn nn nnn nnn nnn nnn nnn nnn nnn nnn nn nn nn nnn nnn nnn n ee */ 587 
588 /* End the Job */ 588 
589 /* A release is sent to each program device to end the sessions, and */ 589 
590 /* the ICF, display, and printer files are closed. */ 590 
591 | res */ 591 
592 592 
593 void end_job() 593 
594 { 594 
595 1 _Rrelease(icffptr, "ICFOO"); 595 
596 2 _Rrelease(icffptr, "ICFO1"); 596 
597 3 _Rrelease(icffptr, "ICFO2"); 597 
598 4 _Rrelease(icffptr, "ICF03"); 598 
599 5 close_files(); 599 
600 } 600 
601 601 
602 602 
603 [Bannon nnn nnn nnn nnn nn nn nn nnn nnn nnn nn nn nnn nnn nnn nnn nn nnn nnn n nen e- */ 603 
604 /* Close the Files */ 604 
605 /* Close the ICF, display, and print files. */ 605 
606 | eres */ 606 
607 607 
608 void close_files() 608 
609 { 609 
610 1 _Rclose(icffptr); 610 
611 2 _Rclose(dspfptr) ; 611 
612 3 _Rclose(prtfptr) ; 612 
613 } 613 
614 614 
615 615 
616 [anon nn nn nnn nnn nnn nnn nn nn nnn nnn nnn nnn nn nnn nn nnn nnn nnn n nena ee */ 616 
617 /* Print Message */ 617 
618 /* Write message and return code to print file. */ 618 
619 | Peres */ 619 
620 620 
621 void print_msg(int mtype) 621 
622 { 622 
623 if get_access_to_fb(); 623 
624 2 strncpy(print_rec.major, dsp_icf_fdbk->major_ret_code, 2); 624 
625 3 strncpy(print_rec.minor, dsp_icf_fdbk->minor_ret_code, 2); 625 
626 4 strncpy(print_rec.filler, " Wo) 626 
627 5 _Rwrite(prtfptr, "RETURN CODE: M36) y 627 
628 6 _Rwrite(prtfptr, &print_rec, sizeof (print_rec)); 628 
629 7 if (mtype == NORM_END 629 
630 8 _Rwrite(prtfptr, "PROGRAM CSRCDMUL COMPLETED NORMALLY ", 36); 630 
631 else 631 
632 9 if (mtype == RCD_ERR) 632 
633 10 _Rwrite(prtfptr, "RECORD FORMAT IS INCORRECT ON READ ", 36)3 633 
634 else 634 
635 ll _Rwrite(prtfptr, "PROGRAM ENDED DUE TO ERROR IN CMNFIL", 36); 635 
636 } 636 
637 637 
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638 638 
639 [kann nnn nnn nnn nnn nnn en nn nn nnn nnn nnn nnn nnn nn nnn nnn nn nnn nnn nnn nnn nn nee */ 639 
640 /* Get Access to DSP/ICF Feedback */ 640 
641 /* The feedback areas are updated after each display or ICF file I/0 */ 641 
642 /* operation, and so the pointers must be updated to point to the "new" */ 642 
643 /* feedback areas to get the return code. The offset to the display/ */ 643 
644 /* ICF feedback area is contained in the common I/0 feedback and is */ 644 
645 /* added to the pointer to the common feedback area to get access to */ 645 
646 /* display/ICF feedback area. */ 646 
647 | baratatatatatatatatatatatatatatatatatatatattatatatatetatatatatatatatedatatatatetatetatateatatatatataataattaatataataataaataatatatel */ 647 
648 26 | 648 
649 void get_access_to_fb() 649 
650 { 650 
651 1 comm_fdbk = _Riofbk(icffptr); 651 
652 dsp_icf_fdbk = (_XXIOFB_DSP_ICF_T *)((char *)comm_fdbk + 652 
653 2 comm_fdbk->file_dep_fb_offset) ; 653 
654 } 654 


exe *e* END OF SOURCE ** * * * 


kK RK KK INCLUDES kK kK KKK 


INCNO Include Name Actual Include Name 

1 dspf CICFLIB/dspfil (*al1) 

2 icff/itmrsp CICFLIB/cmnfil (itmrsp) 
3. icff/dtirsp CICFLIB/cmnfil(dtIrsp) 
4 icff/itmreq CICFLIB/cmnfil (itmreq) 
5 icff/dtlreq CICFLIB/cmnfil (dtlreq) 
6 stdio.h QCC/H/STDIO 

7 stddef.h QCC/H/STDDEF 

8 errno.h QCC/H/ERRNO 

9  signal.h QCC/H/SIGNAL 

10 ctype.h QCC/H/CTYPE 

11. stdarg.h QCC/H/STDAR 

12. recio.h QCC/H/RECIO 

13. xxfdbk.h QCC/H/XXFDBK 

14. stdlib.h QCC/H/STDLIB 

15 stddef.h QCC/H/STDDEF 

16 = string.h QCC/H/STRING 

17 xxfdbk.h QCC/H/XXFDBK 

18 xxcvt.h QCC/H/XXCVT 

ee ee * END OF INCLUDES ***** 


xe ee * MESSAGE SUMMARY ** * * * 


Total Info(0-4) Warning (5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
) ) () ) ) () 
xe exe * END OF MESSAGE SUMMARY ** * * * 

ROUTINE BLOCK NUMBER SCOPE TYPE 

<MAIN> 2 LOCAL MAIN-PROGRAM 
__reads 115 LOCAL PROCEDURE 
__rwrite 118 LOCAL PROCEDURE 
__rfmt 125 LOCAL PROCEDURE 
__memset 172 LOCAL PROCEDURE 
__strncmp 190 LOCAL PROCEDURE 
__strncpy 192 LOCAL PROCEDURE 
QXXDTOZ 204 LOCAL PROCEDURE 
QXXZTOD 209 LOCAL PROCEDURE 
QXXZTOI 210 LOCAL PROCEDURE 
evoke_targe 229 ENTRY — PROCEDURE 
process _item_req 230 ENTRY — PROCEDURE 
send_item_req 231 ENTRY — PROCEDURE 
rec_item_info 232 ENTRY PROCEDURE 
calc_profit_loss 233 ENTRY — PROCEDURE 
process _cust_req 234 ENTRY — PROCEDURE 
send_cust_req 235 ENTRY — PROCEDURE 
rec_cust_info 236 ENTRY — PROCEDURE 
pos_ret_code 237 ENTRY — PROCEDURE 
check_no_data 238 ENTRY — PROCEDURE 
check_timeout 239 ENTRY — PROCEDURE 
detach 240 ENTRY — PROCEDURE 
end_job 241 ENTRY PROCEDURE 
close_files 242 ENTRY — PROCEDURE 
print_msg 243 ENTRY — PROCEDURE 
get_access_to_fb 244 ENTRY — PROCEDURE 
main 245 ENTRY PROCEDURE 
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CFILE 
An ICF file used to send records to and receive 
records from the source program. It is done with 
the file-level INDARA DDS keyword, indicating a 
separate indicator area. 


PFILE 


A database file used to retrieve the record for the 
item requested from the remote system. 


QSYSPRT 
A printer file used to print error messages resulting 
from communications errors. 


DDS Source: The DDS for the ICF file (CFILE) is illustrated 
below. 


SOURCE FILE. ...... QICFPUB/ICFLIB 
MEMBER ......... PFILE 
SEQNBR# sos Feces de ache ewig 3S) sae tess Aes he ts UD Men Rarts 
100 A LIFO 
200 A R DBREC 
300 A RECCUS 1 
400 A DBSEQ 6 
500 A DBDATA 130 
600 A DBFILL 13 
700 A K DBSEQ 


**** END OF SOURCE 


Program Explanation: The following explains the structure 
of the program example illustrated in Figure 9-10 on 

page 9-27. The ICF file used is defined by the user, and 
uses externally described data formats (DDS). The refer- 
ence numbers in the explanation below correspond to the 
numbers in the following program example. 


Es External file descriptions are included for the ICF file 
(CFILE). 


CFILE is the ICF file used to send records to and 
receive records from the remote system. CFILE is 
implemented with the file-level keyword, INDARA, indi- 
cating that a separate indicator area is used. 


HZ _s This structure is used to print the return code to the 
printer file QOYSPRT. Output to QSYSPRT is by 
record, so the filler field is used to blank out characters 
that may have been set by a previous write operation 
to the printer file. See FE and Fj. 


The variables to be used globally by the program are 
defined here. The common and display/ICF feedback 
area pointers, the file pointers, and the ICF file sepa- 
rate indicator area are defined. 


Diep nnn na car iS SGI ISSO EI IIIS ISIC INI IIS III IIa 


Ax * 
Ax ICF FILE * 
Ax USED IN TARGET MULTIPLE SESSION PROGRAM * 
Ax * 
Dx SEES IEEE SISOS GEE TOI IEEE IG IAI III TTR TO TR IR IIA. 
A INDARA 

A 05 RQSWRT 

A 10 ALWWRT 

A INDTXT(10 '10 END TRANS.') 
A 15 EOS 

A 20 FAIL 

A INDTXT(20 '20 F ABORT ST') 
A RCVFAIL(25 ‘RECEIVED FAIL') 
A 30 DETACH 

A INDTXT(30 '30>DETACH TGT') 
A RCVDETACH(44 'RECV DETACH') 
A RCVTRNRND(40 ‘END OF TRN') 
A R SNDPART 

A INVITE 

A RECTYP 1 

A ITEMNO 6 

A EDATA 130 

A FILL 13 

A R RCVPART 

A RECID2 6 


The command needed to create the ICF file is: 


CRTICFF FILE(CICFLIB/CFILE) SRCFILE(CICFLIB/QICFPUB) 
SRCMBR(CFILE) ACQPGMDEV(*NONE) TEXT("TARGET ICF FILE 
FOR MULTIPLE SESSION PROGRAM") 


The command needed to define the program device entry is: 
OVRICFDEVE PGMDEV(ICFOQ) RMTLOCNAME (*REQUESTER) 


The DDS source for the database file (PFILE) is illustrated 
below: 


07/02/87 
05/06/87 
10/01/87 
08/18/87 
07/02/87 
10/01/87 
07/04/87 


3s The routines, except the main routine, are prototyped 
so the compiler knows the type of value returned and 
the type of parameters passed, if any. 


Ei sThe ICF, printer, and database files are opened for 
record input, output, or both. The ICF file is opened 
with the separate indicator area option specified. 


[3 The separate indicator area is initialized and defined. 
The variable icf_indic is a character array of size 99. 


The program device ICFOO used by the program is 
explicitly acquired. 


fas This program continues reading from and writing to the 
ICF file until either a detach is received from the 
source program, the source program ends abnormally, 
or an error occurs in the transaction. 


A call to a procedure (section [IK] ) to close the files is 
made before the program ends. 


EJ This function reads data from the ICF file (CFILE) that 
was sent from the remote system. 


A check is made to see if a detach was received (indi- 
cator 44 in CFILE) from the remote system, in which 
case control returns to EJ and the program ends. 
Note that the subscript to the indicator in the separate 
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indicator area array is offset by one since the first indi- 
cator starts at position zero in the array. 


If a turnaround indication is received (indicator 40 in 
CFILE), then the return code is checked for a value of 
3431 (not a serious error) or a 0000. Any other return 
code received causes an error message to be printed 
and the program to end on return to Eq. If the turn- 
around is not received, the program ends. 


The number received from the remote system is used 
to find the corresponding item or customer record by 
key in PFILE. If the record is not found, 000000 is 
sent to the source program. The record ID is set to ‘I’. 


The data is sent to the remote system with an invite, 
and the return code is checked for a successful opera- 
tion. If the major return code is not 00, the program 
ends. 


This function calls a procedure (section [J ) to access 
the display/ICF feedback area. It then checks for a 
3431 return code or a 00 major return code. 
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This function calls a procedure (section [Wj ) to access 
the display/ICF feedback area. It then checks for a 00 
major return code, which indicates that the last opera- 
tion was successful. 


This procedure closes the ICF, printer, and database 
files. 


This procedure retrieves the return code to be printed 
from the display/ICF feedback area and prints a normal 
end message to the printer file. 


This procedure retrieves the return code to be printed 
from the display/ICF feedback area and prints an 
abnormal end message to the printer file. 


This procedure accesses the common I/O feedback 
and the display/ICF feedback areas. The pointers 
must be reset after each I/O operation where informa- 
tion from the feedback areas is needed, so this proce- 
dure is called before checking the return code. 


Program name 
Library name 
Source file 
Library name 
Source member name . . 
Text Description 


x kK KK * 


CTGTDMUL 


PROLOG 


xk KK 


Target C program for ICF Programming 


Compiler options ....... :  ¥*SQURCE *NOXREF *NOSHOWUSR *NOSHOWSYS *NOSHOWSKP *NOEXPMAC *NOAGR 
*NOPPONLY *NODEBUG *GEN *NOSECLVL = *PRINT *LOGMSG 

Language level options ....: *EXTENDED 

Source margins: 
Left margin... ......: «221 
Right margin... . 1... 232 32767 

Sequence columns: 
Left Column. ........32 
Right. Column: 3.406 0 we et 

Define name... .......3 

Generation options ......: *NOLIST *NOXREF *GEN *NOATR *NODUMP *NOOPTIMIZE *NOALWBND 

*NOANNO 

Print file .......... : QSYSPRT 
Library name ........3: *LIBL 

Message flagging level ....: 0 

Compiler message: 
Message limit ........: *NOMAX 
Message limit severity 30 

Replace program object ....: ¥*YES 

User prottle. a. siciae apse ew *USER 

AUtHOPITY “ss -3. ene Bo we, we *LIBCRTAUT 

Target Release ........ :  ¥*CURRENT 

Lastiichange: «as sae hea ae 8 90/09/20 14:46:14 

Source description ......: Target C program for ICF Programming 

Compilers oe ce vee Heo ais es LE IBM ILE C/400 Compiler 

KKK KK SOURCE Kk KKK 
Line STMT SEQNBR = INCNO 
Kathe ce als, oT aetee lena etetawade spate aineeae ’ Ha She D ig wine Pia area Ore esc eh atelg WA wile ade ts oie Bis sete Os eek lees 

1 #pragma mapinc("icff/snd", "cicflib/cfile(sndpart)", "output", "p z") 1 
2 #include "icff/snd" 2 
3 #pragma mapinc("icff/rev", "cicflib/cfile(rcvpart)", "input", "p z") 3 
4 #include “icff/rcv" 4 
5 [anne nn nn nnn nnn nn nnn nnn nn nn nnn nnn nnn nn nn nnn nnn nnn nnn nn nn nnn nnn e en e- */ 5 
6 /* This program will handle the request for either a customer number or */ 6 
7 /* an item number. This is accomplished by making the data base file */ 7 
8 /* structure (key length, key position, record length, record size, */ 8 
9 /* etc.) the same for both files with only the record contents */ 9 
10 /* different. The database file is searched with a customer number or */ 0 
11 /* item number as a key. */ 1 
12 /* This program ends when a detach request is received from the source */ 2 
13 /* program. */ 3 
14 /* Indicators associated with the ICF file are defined and are */ 4 
15 /* referenced for every I/0 operation issued. */ 5 
16 [Bannan nnn nnn nnn nn nn nnn nn nn nnn nnn nn nn nnn nnn nnn nnn nn nn nn nnn nnn n een e- */ 6 
17 i 
18 #define ION '1' /* Indicator set on */ 8 
19 #define IOFF '0' 9 
20 #define ERROR 1 /* Error occurred */ 20 
21 #define NOERROR 0 21 
22 #define TRUE 1 22 
23 #define FALSE 0 23 
24 #include <stdio.h> /* Standard I/0 header */ 24 
25 #include <recio.h> /* Record 1/0 header */ 25 
26 #include <stdlib.h> /* General utilities */ 26 
27 #include <stddef.h> /* Standard definitions */ 27 
28 #include <string.h> /* String handling utilities */ 28 
29 #include <xxfdbk.h> /* Feedback area structures */ 29 
30 30 
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[Been n en nnn nn nn nn nn nn nn nn nn nn nn nn nn nnn nnn ne nn enn een enn */ 
/* Define the structure to be used to write to the print file. */ 
[Been n enn nnn nn nn nnn nn nn nn nn nnn nnn nn nnn nn nnn nnn enn enn ene eee */ 
struct { 


char major??(2??); 
char minor??(2??); 


char filler??(29??); /* Used for padding with blanks */ 
} print_rec; 
Jose scene nce secs tsleesae sscee esse loc lees essen nt eseooe esses ssen i osece */ 
/* Declare global variables. */ 
Peete sustesssncsencsnfi-nshcssesetsessscsulesesececs acu sssdescecseueses */ 
_RFILE *icffptr; /* Ptr to ICF file */ 
_RFILE *prtfptr; /* Ptr to print file */ 
_RFILE *dbfptr; /* Ptr to database file */ 
_RIOFB_T *rio_fdbk; /* Ptr to partial 1/0 feedback */ 
_XXIOFB_T *comm_fdbk; /* Ptr to common I/0 feedback */ 
“XXIOFB_DSP_ICF_T *dsp_icf_fdbk; /* Ptr to dsp/ICF I/0 feedback */ 
char icf_indic??(99??); /* ICF file separate indic area */ 


CICFLIB_CFILE_SNDPART o t sndpart_icf_o; 
CICFLIB_CFILE_RCVPART i_t rcvpart_icf_i; 


int read_cfile(void); 

int send_data(void); 

int check_ret_code(void); 
int pos_ret_code(void); 

void close_files(void); 

void print_norm_end(void) ; 
void print_error_end(void); 
void get_access_to_fb(void); 


main() 
{ 
int error_or_end = FALSE; /* Set if 1/0 error occured */ 
[keno n nono n-ne n 2 -n--  - n  n ne oe ene eee eee */ 
/* Open the ICF and printer files. If an error occurs the */ 
/* program ends. */ 
[keen nnn nnn nnn oe en nn nen nen ee eee eee */ 


if ((icffptr = _Ropen("CICFLIB/CFILE", "“ar+ indicators=y riofb=y")) 
== NULL) 
exit (ERROR) ; 
if ((prtfptr = _Ropen("CICFLIB/QSYSPRT", "wr")) == NULL) { 
_Rclose(icffptr); 
exit (ERROR) ; 


} 

if ((dbfptr = _Ropen("CICFLIB/PFILE", "rr riofb=y")) == NULL) { 
_Relose(icffptr); 
_Rclose(prtfptr); 
exit (ERROR) ; 

} 

6 

[keane n nn nnn nnn n-ne en nn nen enn ee eee eee */ 

/* Set up separate indicator area for the ICF file. */ 

[keno n nono n-ne n-ne nn nn nen een enn eee eee */ 


memset (icf_indic, IOFF, 99); 
_Rindara(icffptr, icf_indic); 


[enone nnn n one-one nn en enn een eee eee */ 
/* Explicitly acquire a session. If an error occurs the */ 
/* files will be closed and the program will end. */ 
[wenn n nnn n nnn nn ne en en nen een enn ee eee eee ee */ 
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01 12 _Racquire(icffptr, "ICFOO"); 

02 13 if (pos_ret_code() == ERROR) { 

03 14 print_error_end(); 

04 15 close _files(); 

05 36:16 exit (ERROR) ; 

06 } 

07 8 | 

08 [kaon nnn nn nnn non nnn nnn nnn nnn nen nnn nnn enn nnn e eee */ 

09 /* Process requests from the source program until a detach */ 

10 /* is received or an error occurs. */ 

11 [*------------------------ 2-2-2 2-222-222-2222 2-2-2222 -------- */ 

12 

13. «17 _Rpgmdev(icffptr, "ICFO0"); 

14 18 while (error_or_end == FALSE) { 

1519 if (read_cfile() == NOERROR) { 

16 §©20 if (send_data() == ERROR) 

17 21 error_or_end = TRUE; 

18 } 

19 else 

20 22 error_or_end = TRUE; 

21 } 

22 23 close_files(); 

23 } 

24 

25 

26 [ko -- 22-22-2222 2-2-2 2-2-2 2-2-2 o nono nnn nnn nnn n nnn ne- on nn eee --- */ 
27 /* Read ICF File */ 
28 /* This routine issues a read operation to the program device. The */ 
29 /* detach indication is checked, and if it was signaled main is */ 
30 /* notified. If the receive turnaround indicator isn't set, or an */ 
31 /* unexpected return code is received, main is notified of an error. */ 
32 es */ 
33 9 | 

34 read_cfile() 

35 { 

36 1 _Rformat(icffptr, "RCVPART") ; 

37 2 memset(icf_indic, IOFF, 99); 

38 3 _Rreadn(icffptr, &rcvpart_icf_i, sizeof(rcvpart_icf_i), _ DFT); 

39 4 if (icf_indic??(43??) == ION) { /* Detach indicator (44) set */ 
40 5 print_norm_end() ; 

41 6 return (ERROR) ; 

42 } 

43 else 

44 7 if (icf_indic??(39??) == ION) /* Rec. turnaround (40) set */ 
45 8 if (check_ret_code() == NOERROR) 

46 9 return (NOERROR) ; 

47 else { 

48 10 print_error_end(); 

49 ll return(ERROR) ; 

50 } 

51 else { 

52 12 print_error_end() ; 

53 13 return(ERROR) ; 

54 } 

55 } 

56 

57 

58 [anne nnn nnn nn nnn nnn nnn nnn nnn nnn nnn nnn nn nnn nnn nnn nnn n nnn n nnn en ee */ 
59 /* Write to ICF File */ 
60 /* A request from the source program results in reading a single record */ 
61 /* containing the requested customer or order number. The response will*/ 
62 /* be returned in a single record containing either the item or customer*/ 
63 /* information, depending on the data base content. */ 
64 /* The response is sent to the source program by writing to the program */ 
65 /* device file using format sndpart. */ 
66 /* The database file is searched by key. If the number of bytes */ 
67 /* returned is 0, then the record was not found on the read, in which */ 
68 /* case "000000" is sent back to the source program. */ 
69 | eres */ 
70 
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send_data() 

{ 
rio_fdbk = Rreadk(dbfptr, &sndpart_icf_o, sizeof(sndpart_icf_o), 

1 __KEY_EQ, rcvpart_icf_i.RECID2, 6); 

2 if (rio_fdbk->num_bytes == 0) { 

3 sndpart_icf_o.RECTYP = 'I'; 

4 strncpy(sndpart_icf_o.ITEMNO, "000000", 6); 


} 
5 _Rformat(icffptr, "SNDPART") ; 
6 _Rwrite(icffptr, &sndpart_icf_o, sizeof (sndpart_icf_o)); 
7 if (pos_ret_code() == NOERROR) 
8 return (NOERROR) ; 
else { 
9 print_error_end(); 
10 return (ERROR) ; 
} 
} 
[Been n nnn nn nn nn nn nn nn nn nn nn nn nn nn nn nnn enn en en nee nen nee eee 
/* Check Return Code 


/* This routine checks the return code after a receive operation for 
/* 0000 and 3431. Anything else is considered an error. 


PResscne cat scenes nse sseesnss cones nsec eee eee sae net ese cee ee ese ei sns-e 
check_ret_code() 
{ 
1 get_access_to_fb(); 
if (strncmp(dsp_icf_fdbk->major_ret_code, "34", 2) == 0 && 
2 strncmp(dsp_icf_fdbk->minor_ret_code, "31", 2) == 0) 
3 return (NOERROR) ; 
else 
4 return(pos_ret_code()); 
} 
[eeestentecses Hones see se see close see eee Sosa ete e eee see este eee Ss 
/* Check for Successful Operation 


/* This routine checks the major return code of 00 to see if the last 


/* operation was successful. 
[Beene nnn nnn nn nnn nnn nn nn nn nn nnn nnn enn en nn nn nen ee ne nee 
pos_ret_code() 
{ 
1 get_access_to_fb(); 
2 if (strncmp(dsp_icf_fdbk->major_ret_code, "00", 2) == @) 
3 return (NOERROR) ; 
else 
4 return (ERROR) ; 
} 
[eesssencecs es Honise tee se ses ets ee ee ee see ee eee eee see ee ese ees 
/* Close the Files 
/* Close the ICF, print, and database files. 
Jeetoent caesar sesso rae sees ese n esse ese cee esse sens soceesecesestisnsee 
void close_files() 
{ 
1 _Rclose(icffptr); 
2 _Rclose(prtfptr) ; 
3 _Rclose(dbfptr) ; 
} 
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237 /* Print Normal End Message */ 237 
238 /* Write normal end message and return code to print file. */ 238 
239 | baretatatatatatatatatatatatatatatatatatatattatatatatetatatatatatatatatatetatatetatetatatatatatatatataatatattaatataataataaatadamtatel */ 239 
240 240 
241 void print_norm_end() 241 
242 { 242 
243 1 get_access_to_fb(); 243 
244 2 strncpy(print_rec.major, dsp_icf_fdbk->major_ret_code, 2); 244 
245 3 strncpy(print_rec.minor, dsp_icf_fdbk->minor_ret_code, 2); 245 
246 4 strncpy(print_rec.filler, " ", 29); 246 
247 5 _Rwrite(prtfptr, "RETURN CODE: 5 °33)3 247 
248 6 _Rwrite(prtfptr, &print_rec, sizeof (print_rec)); 248 
249 7 _Rwrite(prtfptr, "CTGTDMUL HAS COMPLETED NORMALLY ", 33); 249 
250 } 250 
251 251 
252 252 
253 [kann nnn nnn nnn nnn nn nnn nn nnn nn nnn nn nnn nnn nnn nnn nnn nn nnn nn nnn nnn nnn n nn nne */ 253 
254 /* Print Abnormal End Message */ 254 
255 /* Write abnormal end message and return code to print file. */ 255 
256 | baratatetatatatatatatatatatatatatatatatatatatatatatatatatatatatatatatetatetatatetatatatatetatatatatatatatetatetatatatettaatetatatatatatel */ 256 
257 257 
258 void print_error_end() 258 
259 { 259 
260 if get_access_to_fb(); 260 
261 2 strncpy(print_rec.major, dsp_icf_fdbk->major_ret_code, 2); 261 
262 3 strncpy(print_rec.minor, dsp_icf_fdbk->minor_ret_code, 2); 262 
263 4 strncpy(print_rec.filler, " ", 29); 263 
264 5 _Rwrite(prtfptr, "RETURN CODE: W338) 264 
265 6 _Rwrite(prtfptr, &print_rec, sizeof (print_rec)); 265 
266 7 _Rwrite(prtfptr, "CTGTDMUL HAS COMPLETED ABNORMALLY", 33); 266 
267 } 267 
268 268 
269 269 
270 [anna nnn nnn nn nnn nn nn nn nnn nn nnn nn nnn nn nnn nnn nnn nnn nn nnn nn nnn nnn */ 270 
271 /* Get Access to DSP/ICF Feedback */ 271 
272 /* The feedback areas are updated after each display or ICF file I/0 */ 272 
273 /* operation, and so the pointers must be updated to point to the "new" */ 273 
274 /* feedback areas to get the return code. The offset to the display/ */ 274 
275 /* ICF feedback area is contained in the common I/0 feedback and is */ 275 
276 /* added to the pointer to the common feedback area to get access to */ 276 
277 /* display/ICF feedback area. */ 277 
278 | baetatetatatatatatatatatatatatatatatatatattatatatattatatatateatatatatetatatetatetatatatatatatatatatatatattatatetattatataattaataetatel */ 278 
279 279 
280 void get_access_to_fb() 280 
281 { 281 
282 1 comm_fdbk = _Riofbk(icffptr); 282 
283 dsp_icf_fdbk = (_XXIOFB_DSP_ICF_T *)((char *)comm_fdbk + 283 
284 2 comm_fdbk->file_dep_fb_offset); 284 
285 } 285 


x**x*e*e* END OF SOURCE ** * & & 
Figure 9-10 (Part 5 of 6). Target Program Example — CTGTDMUL (User-Defined Formats) 
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kK KKK INCLUDES kK kK KKK 
INCNO Include Name Last change Actual Include Name 
1 icff/snd CICFLIB/cfile(sndpart) 
2. icff/rev CICFLIB/cfile(rcvpart) 
3 stdio.h 90/09/12 14:42:23 QCC/H/STDIO 
4 stddef.h 90/09/12 14:42:22 QCC/H/STDDEF 
5 errno.h 90/09/12 14:42:18 QCC/H/ERRNO 
6 signal.h 90/09/12 14:42:22 QCC/H/SIGNAL 
7 ctype.h 90/09/12 14:42:18 QCC/H/CTYPE 
8 stdarg.h 90/09/12 14:42:22 QCC/H/STDARG 
9 recio.h 90/09/12 14:42:21 QCC/H/RECIO 
10 = xxfdbk.h 90/09/12 14:42:28 QCC/H/XXFDBK 
11s stdlib.h 90/09/12 14:42:24 QCC/H/STDLIB 
12. stddef.h 90/09/12 14:42:22 QCC/H/STDDEF 
13. string.h 90/09/12 14:42:24 QCC/H/STRING 
14 xxfdbk.h 90/09/12 14:42:28 QCC/H/XXFDBK 
x****e* END OF INCLUDES ***** 


xe ee * MESSAGE SUMMARY ** * * * 


Total Info(0-4) Warning (5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
0 () 0 0 () 0 
eee ** END OF MESSAGE SUMMARY ** * * * 

ROUTINE BLOCK NUMBER SCOPE TYPE 

<MAIN> 2 LOCAL MAIN-PROGRAM 

__reads 115 LOCAL PROCEDURE 

__readk 117 LOCAL PROCEDURE 

__rwrite 118 LOCAL PROCEDURE 

__rfmt 125 LOCAL PROCEDURE 

__memset 172 LOCAL PROCEDURE 

__strncmp 190 LOCAL PROCEDURE 

__strncpy 192 LOCAL PROCEDURE 

read_cfile 213 ENTRY |= PROCEDURE 

send_data 214 ENTRY = PROCEDURE 

check_ret_code 215 ENTRY — PROCEDURE 

pos_ret_code 216 ENTRY = PROCEDURE 

close_files 217 ENTRY | PROCEDURE 

print_norm_end 218 ENTRY = PROCEDURE 

print_error_end 219 ENTRY = PROCEDURE 

get_access_to_fb 220 ENTRY — PROCEDURE 

main 221 ENTRY = PROCEDURE 

**e**e*e* END OF COMPILATION ** * * 


Figure 9-10 (Part 6 of 6). Target Program Example — CTGTDMUL (User-Defined Formats) 


9-32 —ICF Programming V4R1 


Chapter 10. COBOL/400 Communications Applications 


Previous chapters in this book describe the functions pro- 
vided by ICF. This chapter introduces you to the 
COBOL/400 interfaces for ICF and provides program exam- 
ples. 


Two application examples are presented in this chapter. For 
each example, both the source and target programs are pro- 

vided. Each program is written first with user-defined formats 
(data description specifications, DDS) and then with system- 

supplied formats. 


The first example in this section is a batch data transfer 
application using a single session. The second example is a 
multiple-session inquiry application using one display file and 
four ICF sessions. 


Not all programming considerations or techniques are illus- 
trated in each example in this section. Review these exam- 
ples and the examples provided in the appropriate 
programming book before beginning application design and 
coding. 


Note: The examples in this section were written to the 
APPC communications type. Minor changes might be 
required if another communications type is used. 


Introduction to the COBOL/400 Interface 


Before you write a COBOL/400 communications application, 
you must understand the high-level language interface pro- 
vided by the COBOL/400 programming language. 


The operations you use in the communications portion of 
your program are similar to work station operations. ICF files 
are defined as transaction files in the COBOL/400 program- 
ming language. In the noncommunications portion of your 
program, you can use all noncommunications operations you 
normally use to process data that is sent or received 
between your program and the remote program. 


Figure 10-1 briefly introduces the COBOL/400 statements 
you use in the communications portion of your program. 


Figure 10-1. COBOL/400 Statements 


ICF COBOL/400 

Operation Statement Function 

Open OPEN Opens the ICF file 

Acquire ACQUIRE Establishes a session 

Get-Attributes ACCEPT Gets the attributes of a session 

Read READ1 Receives data from a specific 
program device 

Read-from- READ1 Receives data from any invited 

invited- program device2 


program-devices 


© Copyright IBM Corp. 1997 


Figure 10-1. COBOL/400 Statements 


ICF COBOL/400 

Operation Statement Function 

Write WRITE Performs many of the ICF com- 
munications functions within a 
session 

Release DROP Releases the session 

Close CLOSE Closes the ICF file 


1 A COBOL/400 read operation can be directed either to a spe- 
cific program device or to all invited program devices. The 
support provided by the COBOL/400 compiler determines 
whether to issue an ICF read or read-from-invited-program- 
devices operation based on the presence of a format name or 
a terminal name on the read operation. For example, if a 
READ is sent with a specific format or terminal specified, the 
read operation is interpreted as an ICF read operation. Refer 
to the COBOL/400 language book for more information. 


2 The read-from-invited-program-devices operation could com- 
plete without data if the timer interval established with either 
the timer function or WAITRCD expires, or your job is ended 
(controlled). 


Refer to the LE COBOL/400 Reference for details on the 
syntax and function of each operation. 


Error Handling: The FILE STATUS clause of the 
FILE-CONTROL paragraph is used in COBOL/400 program- 
ming to specify the variables for the COBOL file status and 
the ICF major and minor return codes. 


Figure 10-2 shows the file status values as returned by 
COBOL/400 after an input/output (I/O) operation for each 
major and minor return code. Use this list to determine the 
ICF return code or group of codes that corresponds to the 
file status value. 


Figure 10-2 (Page 1 of 2). File Status 
Values for Major and Minor Return Codes 


ICF COBOL/400 
Return Code Return Code 
00Oxx 00 

02xx 9A 

03xx 00 

0309 9A 

04xx 9l 

0800 00 

1100 10 

34xx 9G 

80xx 30 

81xx 92 

82xx 9C 

83xx ON 
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Figure 10-2 (Page 2 of 2). File Status 
Values for Major and Minor Return Codes 


ICF COBOL/400 
Return Code Return Code 


83E0 9K 


Accessing the Feedback Areas: Use the COBOL/400 
ACCEPT statement to obtain the open or I/O feedback infor- 
mation for an ICF file. 


The COBOL/400 offset values for the open and I/O feedback 
areas are the same as those listed in Appendix C. 


Example Programs 


The programs presented in this section are: 
e Example | (Batch Data Transfer) 


Figure 10-3 shows a batch data transfer program that 
reads a database file and sends the data to a remote 
system. When the source program finishes sending its 


Local AS/400 System 


records, it sends an indication that it is done sending 
records to the target program. The target program then 
starts sending its records until it reaches end-of-file. At 
end-of-file, the target program sends a detach indication 
to the source program. The two programs end their ses- 
sions. 


e¢ Example Il (Multiple-Session Inquiry) 


Figure 10-4 on page 10-3 shows an inquiry program 
that accepts inquiries from a display device, sends the 
request to one of four remote AS/400 systems, and 
waits for a response to the inquiry. Based on the input 
received from the display device, the program deter- 
mines the target program to which it sends the inquiry 
request. The same program resides in each of the 
remote systems. 


Figure 10-4 on page 10-3 contains a display device and 
four ICF communication program devices. 


The remainder of this chapter discusses the details of the 
two application examples. The DDS file, program listings, 
and an explanation of the programs are included. 


Remote AS/400 System 


Database] | Program ICF 
File File 


ICF Program, |Database| | 
File File 


Figure 10-3. Batch Data Transfer 
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Figure 10-4. Multiple-Session Inquiry 
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Remote AS/400 System 
ICF Program Database 
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Remote AS/400 System 
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Batch Data Transfer (Example 1) 


The following figures show a batch data transfer program. A 
source AS/400 system program communicates with a target 
program on another AS/400 system using the ICF support. 
The source program starts a target program on a remote 
AS/400 system and transfers a file to that target program. 


The target program responds, after receiving an indication 
that the source is done sending, by reading its own file and 
then sends the records to the source program until it reaches 
end of file. At end-of-file, the target program sends a detach 


request to the source program and ends its session. 


Local AS/400 System 


Both the source program and the target program are 
described. 


Transaction Flow of the Batch Data Transfer 
(Example I): In Figure 10-5, the source program issues 
an evoke to start a program at the remote AS/400 system. 


Note: An acquire operation is not necessary since the 
device was acquired during the open operation. The device 
was acquired during the open operation because the 
ACQPGMDEV parameter was used when the ICF file was 
created. 


Remote AS/400 System 


| | Database 


File 


Program 


Write 
[-——- 


ICF 


Evoke || ICF Program 


File 


File 


Figure 10-5. Evoke Request Starts a Target Program 


After issuing the evoke request, the source program sends a 
database file to the target program, which prints the records 
as shown in Figure 10-6. 


Local AS/400 System 
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Remote AS/400 System 
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Figure 10-6. Target Program Prints Records 


After the target program receives and prints the file, a data- 
base file is sent to the source program. The source program 


AS/400 System 
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prints the records as they are received, as shown in 
Figure 10-7. 
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Figure 10-7. Source Program Prints the Received Records 
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Once all the records have been sent by the target program, 
the target program issues a detach to the source program to 
end the transaction, as shown in Figure 10-8 on page 10-5. 


Local AS/400 System 


Remote AS/400 System 


Printer Program Read fae Detach ICF Write Program Database 
File File ha File File 
Figure 10-8. Target Program Ends the Transaction 
DEO I IOI II IR I IORI I I TORII II TOI III ITI III SI III IIIS ISI I IIIS AIH. 
Source Program Batch Transfer (Example I): The Ae * 
j j Ax ICF FILE * 
following describes the COBOL/400 batch data transfer a Hise AW AAGEU Geen TRANG PARA : 
source program. Ax x 
DAI IOI II IR I IORI I I TORII I I TOI II I ITI II IAI III IIIS III I IIIS AI 
, Ax 
Program Files: The COBOL/400 batch transfer source Ax FILE LEVEL INDICATORS: 
. . Ax 
program uses the following files: 7 Gana 
Ax 
SRCICF A RCVTRNRND(15 'END OF DATA') 
An ICF file used to send records to and receive . a4 NevacH 
records from the target program. Ae 
A NDTXT(30 '30->DETACH TARG- 
DBFILE A ET PROGRAM. ') 
. fe Ax 
A database file that contains the records to be sent A RCVDETACH(35 ‘RECEIVED - 
A DETACHED. ') 
to the target program. a 
Ax 
A printer file used to print the records received from h cintccn beige ete eager 
the target program. R RCVDATA 
RCVFLD 80A 
ri as fd R SNDDATA 
DDS Source: The DDS source used in the ICF file is illus- SNDFLD 80A 
j H H R EVOKPGM 
trated in the following example. The other files (DBFILE and fe 286 stoner etanvapeniby 
QPRINT) are program-described and therefore require no A 50 SECURITY (2 oe + 
3 'USERID' 
DDS. A PGMID 10A P 
A LIB 10A P 
A R ENDREC 
A R INVITE 
A 45 INVITE 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/SRCICF) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(SRCICF) ACQPGMDEV(PGMDEVA) TEXT('ICF FILE FOR 
BATCH DATA TRANSFER') 


The command needed to define the program device entry is: 


ADDICFDEVE FILE(ICFLIB/SRCICF) PGMDEV(PGMDEVA) 
RMTLOCNAME (CHICAGO) 


Program Explanation: The following describes the struc- 
ture of the program examples illustrated in Figure 10-9 on 
page 10-7 and Figure 10-10 on page 10-13. The ICF file 
used in the first example id defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference numbers 
in the explanation below correspond to the numbers in the 
following program examples. 
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Although the basic structure of the two examples provided is 
the same, there are differences because of the use of user- 
defined formats and system-supplied formats. 


Differences between the first and second example are docu- 
mented as notes in each of the descriptions. 
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This section identifies the files used in the program. 
SRCICF is the ICF file used to send records to the 
target program. 


This section also contains declarations of I/O variables, 
work areas and constants needed. MAJ-MIN contains 
the major/minor return code from the I/O feedback 
area. 


Note: In the program using system-supplied formats, 
the input records for SRCICF are explicitly coded since 
SRCICEF is now treated as a program-described file. 
The system-supplied file, QICDMF, can be used 
instead of SRCICF. This can be done by specifying 
QICDMF in the file specification, or by using an over- 
ride ICF file (OVRICFF) command to change the file 
name from SRCICF to QICDMF. The OVRICFF 
command can also be used to change the 
ACQPGMDEV parameter of the file. 


This section defines the error handling for the program. 
The major/minor return code is checked to determine 
whether the error is recoverable. If the error is recov- 
erable (major/minor code 83xx or 03xx), it sets a flag 
(ERR-SW) to 1 and returns to the program. 


If any other error has occurred, the program writes the 
feedback data to a file (DFILE), calls a program to print 
DFILE, and then ends. 


The program opens the files that are going to be used 
as follows: 


DBFILE 
The database file used as input for transmit- 
ting to the target program. 


QPRINT 
The printer file used as output for records 
received 


SRCICF 
The ICF file used to send data to and receive 
data from the target program 


Because the ICF file was created using the 
ACQPGMDEV parameter, the program device is auto- 
matically acquired when the file is opened. Therefore, 
no acquire operation is coded in the program. 


If the ERR-SW flag is set to 1, indicating that a recov- 
erable error has occurred, the program determines 
whether the open retry count limit (9) has been 
exceeded. If it has, the program goes to —&J. If the 
limit count is less than 9, one is added to the count 
and control passes to [J. Control then passes to 
to attempt to open the file. 
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The evoke request is built and sent to the remote 
system. Because the DDS for the record format only 
specifies the field identifiers with the record, the code 
in this section of the program moves the literal value 
CTDBATCL to the field PGMID, and ICFLIB to the field 
LIB. Indicator 50 is set to indicate that the program 
start request is to be sent. 


When the program start request is received at the 
remote system, ICFLIB is searched for CTDBATCL and 
that program is then started. CTDBATCL is a control 
language (CL) program that contains the following 
statements: 


ADDLIBLE ICFLIB 
CALL ICFLIB/CTDBAT 


Note: In the program using system-supplied formats, 

the library and program (ICFLIB/CTFBATCL) are speci- 
fied as part of the $$EVOKNI format. CTFBATCL is a 
CL program that contains the following statements: 


ADDLIBLE ICFLIB 
CALL ICFLIB/CTFBAT 


Data is read from the database file. If the record read 
is end-of-file, the program sets the EOF-DBFILE-SW, 
performs routine to invite the program device, and 
goes to &g. 


If it is not the last record, the data is moved to the 
output buffer and the program goes to [J to write the 
record to the program device. When control returns 
from J, the process is repeated (DBFILE read) until 
end-of-file. 


Data is read from the ICF file (SRCICF). If the opera- 
tion was successful, and data was received (major 
return code not = ‘03’), then the data is written to the 
printer file (QPRINT). If an error occurs on the read, 
control passes to [XJ to attempt recovery. When 
control returns from [QJ, control passes to Ej to 
attempt to open the files. 


Data is read until the detach indication is received from 
the target program. When detach is received, indicator 
35 is set on, as defined by the RCVDETACH keyword 

in the DDS for the ICF file. Note that RCVDETACH is 

a file-level keyword. 


Note: In the program using system-supplied formats, 
the minor return code of '08' is checked to verify 
whether detach is received. 


After the detach request has been received, this 
routine writes the following message to the printer file: 
CSDBAT HAS COMPLETED NORMALLY 


The files are closed. The program device is automat- 
ically released as a result of the close operation. 


Note: In the program using system-supplied formats, 
the program name is CSFBAT. 


This routine is performed to write data to the ICF file 
using the format SNDDATA. If an error occurs on the 
write, control passes to QJ and then finally to Kj. 


Note: In the program using system-supplied formats, 
the $$SENDNI format is used instead of the user- 
defined SNDDATA format. 


EQ] This routine is performed when a recoverable session 
error has occurred. It closes the files (SRCICF, 
QPRINT and DBFILE) and sets the error switch 
(ERR-SW) to 0. Control then returns to the statement 
immediately following the PERFORM statement that 
passed control to this routine. 


This routine is performed when the application receives 
a major/minor return code of 03xx or 83xx after it has 
already attempted to recover 9 times from session 
errors that caused the error. The program is designed 


to tolerate only nine failures. It writes the following 
message to the printer file: 


CSDBAT HAS COMPLETED ABNORMALLY 
The session is ended. 


Note: In the program using system-supplied formats, 
the program name is CSFBAT. 


This routine is performed to issue an invite request to 


the program device using format INVITE. If an error 
occurs, control passes to [QJ and then finally to Kj. 


Note: In the program using system-supplied formats, 
the $$SEND format is used instead of the user-defined 
INVITE format. 


Program: 30 y.660 ee eee oa ee ee oe ee — CSDBAT 
LI DRany™ seo ces oe Ga a es hoe ee EE ICFLIB 
Source: File. 3) we. aw ce a aS QICFPUB 
ET DRAT YS sg. Seay cee ce trv ede eect! Sr es ee TE ICFLIB 
Source member ........... =: CSDBAT 02/28/89 13:51:38 
Generation severity level .....: 29 
Text 'description'......... :  cobol batch file transfer using dds (source) 
Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........ : + *NOMAX 
Message limit severity ......: 29 
Print file. ........ 2... . 2:  QSYSPRT 
MEDAN sh ests et Ge ratne, See aes et Soh eee *LIBL 
FIPS flagging ........... :  *NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ......... +... :  ¥*NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release. . 2... ... ~~ 3) *CURRENT 
User profile. ........... :  *USER 
Authority oe eee ee ee | *ETBCRTAUT 
Compiler... ...... 4.4. 2 IBM AS/400 COBOL/400 
1 000100 IDENTIFICATION DIVISION. 02/21/89 
000200 PROGRAM-ID. CSDBAT. 02/21/89 
QOO3 OD kx KAA KK ARK KARR KK RRR RRR KERR RE RRR RRR ERE E RRR RR KKK ERE ERE ER EER RE 02/21/89 
000400* THIS IS A BATCH FILE TRANSFER PROGRAM THAT READS A SEQUENTIAL * 02/21/89 
000500* FILE AND SENDS THE RECORDS TO THE REMOTE SYSTEM UNTIL THE END * 02/21/89 
000600* OF FILE IS REACHED. AT THIS TIME, THE PROGRAM STOPS SENDING * 02/21/89 
000700* AND STARTS RECEIVING RECORDS FROM THE REMOTE SYSTEM UNTIL * 02/21/89 
000800* A DETACH INDICATION IS RECEIVED. * 02/21/89 
QOOQOO Kx xR AAR KAA KAA K KEKE RRR RRR KER EKER EK RRR KER EKER EKER RR ERE RE RE RERERERERER RE 02/21/89 
3 001000 ENVIRONMENT DIVISION. 10/16/87 
4 01100 CONFIGURATION SECTION. 10/16/87 
5 001200 SOURCE-COMPUTER. IBM-AS400. 02/21/89 
6 001300 OBJECT-COMPUTER. IBM-AS400. 02/21/89 
7 001400 SPECIAL-NAMES. I-0-FEEDBACK IS FEEDBACK-AREA 10/16/87 
8 001500 OPEN-FEEDBACK IS OPEN-FBA. 10/16/87 


Figure 10-9 (Part 1 of 6). Source Program Example — CSDBAT (User-Defined Formats) 
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9 001600 INPUT-OUTPUT SECTION. 10/16/87 


10 001700 FILE-CONTROL. 10/16/87 
001800 f 10/16/87 
11 001900 SELECT DBFILE ASSIGN TO DATABASE-DBFILE. 10/16/87 
12 002000 SELECT SRCICF ASSIGN TO WORKSTATION-SRCICF-SI 10/16/87 
13 002100 ORGANIZATION IS TRANSACTION 10/16/87 
14 002200 FILE STATUS IS STATUS-IND MAJ-MIN. 10/16/87 
15 002300 SELECT DFILE ASSIGN TO DATABASE-HEXDUMP. 10/16/87 
16 002400 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 10/16/87 
17 002500 DATA DIVISION. 10/16/87 
18 002600 FILE SECTION. 10/16/87 
19 002700 FD DBFILE 10/16/87 
20 002800 LABEL RECORDS ARE STANDARD. 10/16/87 
21 002900 61 DBREC. 10/16/87 
22 003000 05 DBREC-DATA PIC X(80). 10/16/87 
23 003100 FD SRCICF 10/16/87 
24 003200 LABEL RECORDS ARE STANDARD. 10/16/87 
25 003300 01 ICFREC. 10/16/87 
26 003400 COPY DDS-ALL-FORMATS OF SRCICF. 10/16/87 
27 +000001 05 SRCICF-RECORD PIC X(80). <-ALL-FMTS 
+000002* INPUT FORMAT:RCVDATA FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000003* <-ALL-FMTS 
28 +000004 05 RCVDATA-I REDEFINES SRCICF-RECORD. <-ALL-FMTS 
29 +000005 06 RCVFLD PIC X(80). <-ALL-FMTS 
+000006* OUTPUT FORMAT:RCVDATA FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000007* <-ALL-FMTS 
30 +000008 05 RCVDATA-0 REDEFINES SRCICF-RECORD. <-ALL-FMTS 
31 +000009 06 RCVFLD PIC X(80). <-ALL-FMTS 
+000010* INPUT FORMAT:SNDDATA FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000011* <-ALL-FMTS 
32 +000012 05 SNDDATA-I REDEFINES SRCICF-RECORD. <-ALL-FMTS 
33 +000013 06 SNDFLD PIC X(80). <-ALL-FMTS 
+000014* QUTPUT FORMAT:SNDDATA FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000015* <-ALL-FMTS 
34 +000016 05 SNDDATA-0O REDEFINES SRCICF-RECORD. <-ALL-FMTS 
35 +000017 06 SNDFLD PIC X(80). <-ALL-FMTS 
+000018* INPUT FORMAT: EVOKPGM FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000019* <-ALL-FMTS 
+000020* 05 EVOKPGM-I REDEFINES SRCICF-RECORD. <-ALL-FMTS 
+000021* OUTPUT FORMAT: EVOKPGM FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000022* <-ALL-FMTS 
36 +000023 05 EVOKPGM-0 REDEFINES SRCICF-RECORD. <-ALL-FMTS 
37 +000024 06 PGMID PIC X(10). <-ALL-FMTS 
38 +000025 06 LIB PIC X(10). <-ALL-FMTS 
+000026* INPUT FORMAT: ENDREC FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000027* <-ALL-FMTS 
+000028* 05 ENDREC-I REDEFINES SRCICF-RECORD. <-ALL-FMTS 
+000029* OUTPUT FORMAT: ENDREC FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000030* <-ALL-FMTS 
+000031* 05 ENDREC-0 REDEFINES SRCICF-RECORD. <-ALL-FMTS 
+000032* INPUT FORMAT: INVITE FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000033* <-ALL-FMTS 
+000034* 05 INVITE-I REDEFINES SRCICF-RECORD. <-ALL-FMTS 
+000035* OUTPUT FORMAT: INVITE FROM FILE SRCICF OF LIBRARY ICFLIB <-ALL-FMTS 
+000036* <-ALL-FMTS 
+000037* 05 INVITE-0 REDEFINES SRCICF-RECORD. <-ALL-FMTS 
39 003500 FD DFILE 10/16/87 
40 003600 LABEL RECORDS ARE STANDARD. 10/16/87 
41 003700 61 DUMPREC. 10/16/87 
42 003800 05 DUMP-MAJ-MIN PIC X(4). 10/16/87 
43 003900 05 DUMP-RECORD PIC X(400). 10/16/87 
44 004000 FD QPRINT 10/16/87 
45 004100 LABEL RECORDS ARE OMITTED. 10/16/87 
46 004200 61 PRINTREC PIC X(132). 10/16/87 
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004300 WORKING-STORAGE SECTION. 0/16/87 
004400 77 STATUS-IND PIC X(2). 0/16/87 
004500 77 MAJ-MIN-SAV PIC X(4). 10/16/87 
004600 77 EOF-DBFILE-SW PIC X VALUE "0". 0/16/87 
004700 77 ERR-SW PIC X VALUE "0". 10/16/87 
004800 77 INDON PIC 1 VALUE B"1". 0/16/87 
004900 77 INDOFF PIC 1 VALUE B"0". 10/16/87 
005000 77 OPEN-COUNT PIC 9(1) VALUE 0. 0/16/87 
005100 77 LEN PIC 9(10)V9(5) COMP. 10/16/87 
005200 0/16/87 
005300 77 CMD2 PIC X(31) 10/16/87 
005400 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 0/16/87 
005500 01 CMNF-INDIC-AREA. 10/16/87 
005600 05 CMNF-INDIC PIC 1 OCCURS 99 TIMES 0/16/87 
005700 INDICATOR 1. 10/16/87 
005800 01 OPEN-FBA. 0/16/87 
005900 05 FILLER PIC X(75). 10/16/87 
006000 05 RECS-IN-DB PIC 9(09) COMP-4. 0/16/87 
006100 05 FILLER PIC X(45). 10/16/87 
006200 01 MAJ-MIN 0/16/87 
006300 05 MAJ PIC X(2). 0/16/87 
006400 05 MIN PIC X(2). 0/16/87 
006500/ 10/16/87 
006600 PROCEDURE DIVISION. 0/16/87 
006700 DECLARATIVES. 10/16/87 
006800 ERR-SECTION SECTION. 0/16/87 
006900 10/16/87 
007000 USE AFTER STANDARD ERROR PROCEDURE ON SRCICF. 0/16/87 
007100 SRCICF-EXCEPTION. 0/16/87 
007200* 0/16/87 
007300* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION 10/16/87 
007400* 0/16/87 
007500* RECOVERABLE SESSION ERROR. CLOSE XPF-ICF FILE. 10/16/87 
007600 IF MAJ = "03" OR MAJ = "83" 02/21/89 
007700 MOVE "PROGRAM STARTED AGAIN DUE TO SESSION ERROR" 10/16/87 
007800 TO PRINTREC 0/16/87 
007900 WRITE PRINTREC 0/16/87 
008000 MOVE "1" TO ERR-SW 0/16/87 
008100 GO TO EXIT-DECLARATIVES. 10/16/87 
008200* 0/16/87 
COB 3 OO 4 A a HHH KI IK KI IK KK III KK KI IIR IK II TORK KI ITOK IK IIT KK KIT KIKI I IK IKI 02/21/89 
008400* WHEN THERE IS A PERMANENT SESSION ERROR DETECTED, THE MAJOR- * 02/21/89 
008500* MINOR CODE IS PLACED INTO A DATABASE FILE AND THE FILE IS * 02/21/89 
008600* PRINTED IN HEX USING COPYFILE. * 02/21/89 
O08 7 OO 4 HH KKK RAI KKK IKK KAI I IK KK IIT KK KI I IK IKI IT KK KI IK RK II IK KK 02/21/89 
008800* 10/16/87 
008900 GETFBA. 10/16/87 
009000 OPEN OUTPUT DFILE. 0/16/87 
009100 MOVE MAJ-MIN TO DUMP-MAJ-MIN. 10/16/87 
009200 MOVE ICFREC TO DUMP-RECORD. 0/16/87 
009300 WRITE DUMPREC. 10/16/87 
009400 CLOSE DFILE. 0/16/87 
009500 MOVE 31 TO LEN. 0/16/87 
009600 CALL "QCMDEXC" USING CMD2 LEN. 0/16/87 
009700 MOVE "PROGRAM TERMINATED DUE TO ERROR IN XPF-ICF FILE" 10/16/87 
009800 TO PRINTREC. 0/16/87 
009900 WRITE PRINTREC. 10/16/87 
010000 STOP RUN. 0/16/87 
010100« 10/16/87 
010200 EXIT-DECLARATIVES. 0/16/87 
010300 EXIT. 02/28/89 
010400* 0/16/87 
010500 END DECLARATIVES. 10/16/87 
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OOO OO OO Oo SO Ge SO aw OO Oe OO SO Oe So SO Ow OS Oe Ce Oe Oe SO SO Se Se SO OO Oe ee ee eee 


fa) 


0600/ 
0700 START-PROGRAM SECTION. 


0800* 
0900 START-PROGRAM-PARAGRAPH. 

1000+ Ey 

1100 OPEN INPUT DBFILE 

1200 1-0 — SRCICF 

1300 OUTPUT QPRINT. 

1400* 

LB OOK eK KKK KKK KKK KERR KK KKK KKK KKK KKK KKK KKK KEKE KER KKK KKK KKK KKK IKI I KI RERER 
1600* THE FOLLOWING TEST IS TO ATTEMPT RECOVERY IF AN ERROR OCCURS * 
1700* WHEN OPENING THE ICF FILE. * 
LOOK eK KKK KKK KKK KEK KKK KKK KKK KKK KKK KKK KKK KEKE KKK KKK KKK KKK KIKI IKI IR ERE R 
1900+ J 

2000 IF ERR-SW = "1" 

2100 THEN IF OPEN-COUNT IS = 9 

2200 THEN GO TO ABNORMAL-TERMINATION 

2300 ELSE 

2400 ADD 1 TO OPEN-COUNT 

2500 PERFORM ERROR-RECOVERY-RTN 

2600 GO TO START-PROGRAM-PARAGRAPH 

2700 ELSE 

2800 MOVE © TO OPEN-COUNT. 

2900 


BQOO Kee KKK KKK KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK EKER KKK KKK KKK IK IKARIA ERE R 


3100* EVOKE THE PROGRAM "CTDBATCL" ON THE REMOTE SYSTEM IN LIBRARY * 


3200* ICFLIB. INDICATOR IN5Q IS THE EVOKE KEYWORD. * 
B3OQ KKK KKK KKK K EKER KKK KKK KKK KKK KKK KKK KKK KKK KEKE KKK KKK KKK IK IKARIA KERR 
3400+ 


3500 MOVE "CTDBATCL" TO PGMID OF EVOKPGM-O. 
3600 MOVE "ICFLIB" TO LIB OF EVOKPGM-O. 
3700 MOVE INDON TO CMNF-INDIC(50). 

3800 WRITE ICFREC FORMAT IS "EVOKPGM" 

3900 INDICATORS ARE CMNF-INDIC-AREA. 
4000 MOVE INDOFF TO CMNF-INDIC(50) 

4100 IF ERR-SW = "1' 


4200 PERFORM ERROR-RECOVERY-RTN 
4300 GO TO START-PROGRAM-PARAGRAPH. 
4400* 


AB OOK KKK KK KKK KKK KKK K KK KKK KKK KKK KKK KKK KKK KEKE KEKE KKK KKK KIKI KIKI ARIK ERE R 
4600* WHEN THE EVOKE OPERATION IS SUCCESSFUL, A RECORD FROM THE DATA- * 
4700* BASE FILE IS READ AND THEN SENT TO THE TARGET SYSTEM. THIS WILL * 
4800* BE REPEATED UNTIL THE END OF FILE IS REACHED ON THE DATABASE * 
4900* FILE. AT END OF FILE, THE PROGRAM DEVICE IS INVITED AND THE READ = 
5000* OPERATION IS ISSUED TO GET THE DATA FROM THE REMOTE SYSTEM. * 
BOQ KAKA KKK KKK KKK KKK KKK KK KK KKK KKK KKK KK KKK KK IKK KKK KKK KKK RARER ERE RRR RK 
5200* 

5300 SEND-DATA. 

5400+ 

5500 READ DBFILE 

5600 AT END 

5700 PERFORM INVITE-TO-SEND. 

5800 IF EOF-DBFILE-SW NOT = "1" 

5900 MOVE DBREC-DATA TO SNDFLD OF SNDDATA-O 

ERFORM WRITE-SRCICF-RTN 

6100 GO TO SEND-DATA. 


a 
fo} 
fo} 
fas) 
uv 


BB OQ KH KKK AK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK IK KK KKK IK KKK ERE RE RE RE RRR 
6400* A READ OPERATION IS ISSUED TO PROGRAM DEVICE TO CONTINUE * 
6500* RECEIVING DATA FROM THE REMOTE SYSTEM UNTIL THE RCVDETACH INDI- * 
6600* CATOR IS SET. EACH RECORD RECEIVED WILL BE PRINTED ON THE PRINT * 


6700* FILE. * 
ic10 Chi ee 2 ee eS ee SS ee eS 
6900* 


7000 RECEIVE-DATA. 
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7100* 
7200 READ SRCICF INDICATORS ARE CMNF-INDIC-AREA. 
7300 IF ERR-SW = "1" 


7400 PERFORM ERROR-RECOVERY-RTN 

7500 GO TO START-PROGRAM-PARAGRAPH. 

7600 IF MAJ NOT = "03" 

7700 MOVE ICFREC TO PRINTREC 

7800 WRITE PRINTREC. 

7900 IF CMNF-INDIC(35) NOT = INDON 

8000 GO TO RECEIVE-DATA. 

8100* 

S200 KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KEKE KKK KKK KIKI K III K IIR ERE R 
8300* WHEN PROCESSING IS COMPLETED, END OF JOB MESSAGE IS PRINTED. * 
8400* FILES ARE CLOSED AND THE SESSION IS RELEASED. * 


BE OOK RRR KKK KKK KKK EKER KKK RK KKK KKK KKK KKK KKK KKK KERR KKK KKK KKK IK IKARIA KERR 


8800 MOVE "CSDBAT HAS COMPLETED NORMALLY" TO PRINTREC. 
8900 WRITE PRINTREC. 


() 
) 
() 
) 
) 
) 
) 
) 
() 
) 
) 
) 
) 
) 
) 
) 
() 
) 
) 
019000 CLOSE DBFILE 
) 

() 

) 

) 

) 

) 

) 

) 


9100 SRCICF 
9200 QPRINT. 
9300 STOP RUN. 
9400+ 
QB OO 4 KK KR KKK R KR KR KR KAKI KK IKI IKI KIKI K IKK IK KIRK I KIKI AKIRA RK. 
9600* THIS SUBROUTINE SENDS DATA TO THE REMOTE SYSTEM * 
QT OQ KKK KK KK KRHA KAKA KK KKK IK KIKI KI KKK RIKKI KKK RIKKI KIKI AKIRA K. 
9800 WRITE-SRCICF-RTN. 

019900 

020000 WRITE ICFREC FORMAT IS "SNDDATA" 

020100 INDICATORS ARE CMNF-INDIC-AREA. 

020200 IF ERR-SW = "1" 

020300 PERFORM ERROR-RECOVERY-RTN 

020400 GO TO START-PROGRAM-PARAGRAPH. 

020500* 

020600 ERROR-RECOVERY-RIN. 

020700» Fy 

020800 CLOSE SRCICF 

020900 DBFILE 

021000 QPRINT. 

021100 MOVE "0" TO ERR-SW. 

021200* 

CVA Chere eS eS Se ee Se SS Se Se 

021400* WHEN AN ERROR OCCURS ON AN ICF SESSION, INFORMATION ABOUT THE ~* 


021500* ERROR IS PRINTED. * 


2 LO OQ 4 KKK KKK KKK IK KK A IK IK II TKK KI TOK KK II TOK KK IIR IK IKI KK KI 


021700 ABNORMAL-TERMINATION. 


021800» fq 
021900 MOVE "CSDBAT HAS COMPLETED ABNORMALLY" 
022000 TO PRINTREC. 


022100 WRITE PRINTREC. 
022200 STOP RUN. 
022300* 

O22 4 OQ x KKH KK KKK RAK KK KKK IK KAKI K IKI IK KIKI IK KK III KK KI IK IKI IK KK 
022500* WHEN END OF FILE IS DETECTED, AN INVITE OPERATION IS ISSUED TO * 
022600* NOTIFY THE TARGET THAT IT CAN START SENDING DATA. * 
O22 7 OQ x 4 KKH KK KKK KKK IK KK IK IK KIKI KKK ITOK KI I IK KK II TK KK II KIKI I KK KI 
022800 INVITE-TO-SEND. 

022900 FF 

023000 MOVE INDON TO CMNF-INDIC(45). 

023100 MOVE "1" TO EOF-DBFILE-SW. 

023200 WRITE ICFREC FORMAT IS "INVITE" 


023300 INDICATORS ARE CMNF-INDIC-AREA. 
023400 IF ERR-SW = "1" 

023500 PERFORM ERROR-RECOVERY-RTN 
023600 GO TO START-PROGRAM-PARAGRAPH. 


kee ee END OF SOURCE ** * * & 
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* 19 MSGID: LBLO650 SEVERITY: 00 SEQNBR: 002700 

Message . . .. :  Blocking/Deblocking for file 'DBFILE' will 

be performed by compiler-generated code. 

* 26 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 003400 

Message . . . . : No INPUT fields found for format EVOKPGM. 
* 26 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 003400 

Message . . . . : No INPUT fields found for format ENDREC. 
* 26 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 003400 

Message . . . . : No OUTPUT fields found for format ENDREC. 
* 26 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 003400 

Message . . . . : No INPUT fields found for format INVITE. 
* 26 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 003400 

Message . . . . : No OUTPUT fields found for format INVITE. 
* 39 MSGID: LBLO650 SEVERITY: 00 SEQNBR: 003500 

Message . . .. :  Blocking/Deblocking for file 'DFILE' will be 


performed by compiler-generated code. 
xe eee END OF MESSAGES ** * * * 
Message Summary 
Total Info(0-4) Warning (5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
0 


7 2 5 0 0 
Source records read. .......: 236 
Copy records read... ...... a 37, 
Copy members processed ......: 1 
Sequence errors ......4+6-5+-6-.3: 90 
Highest severity message issued . . : 10 


LBLO901 00 Program CSDBAT created in library ICFLIB. 
xe * ** END OF COMPILATION * * * * * 
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Program: —2.° 46-8) vee hy en ay dee a we 
EI DRArY” vee cyte coy, ear vad ook eae Aa os 
Source: file>. w ake we we aD 
ETP DRANY ces Gees Seca ede Bets eee ae 
Source member .........2.-.3: 
Generation severity level .....: 
Text 'description’'.........: 


CSFBAT 
ICFLIB 
QICFPUB 
ICFLIB 
CSFBAT 10/03/90 14:27:28 
29 


cobol batch file transfer using $$FORMAT (source) 


Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........: + *NOMAX 
Message limit severity ......: 29 
Print file... ...... 2... 2:  QSYSPRT 
MET AVAY ©” oes ibs Sen St coke ated ciocechs teak cap etn *LIBL 
FIPS flagging ........... 2 *NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ......... +... : + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release. . 2... . 2... 3) *CURRENT 
User profile. ........... :  *USER 
Authority ........4. 4.4... :  *LIBCRTAUT 
Compiler. ........ 4.4. +: IBM AS/400 COBOL/400 
1 Q00100 IDENTIFICATION DIVISION. 02/21/89 
2 000200 PROGRAM-ID. CSFBAT. 02/21/89 
QOO3 OD kx K KAKA KAKA KKK KKK RK ERK EKER RRR RRR ER RR ER EKER KR ERE ERERERERER RE 02/21/89 
000400* THIS IS A BATCH FILE TRANSFER PROGRAM THAT READS A SEQUENTIAL * 02/21/89 
000500* FILE AND SENDS THE RECORDS TO THE REMOTE SYSTEM UNTIL THE END * 02/21/89 
000600* OF FILE IS REACHED. AT THIS TIME, THE PROGRAM STOPS SENDING * 02/21/89 
000700* AND STARTS RECEIVING RECORDS FROM THE REMOTE SYSTEM UNTIL * 02/21/89 
000800* A DETACH INDICATION IS RECEIVED. * 02/21/89 
OQOOQOD Kx xR KKK KAA KK ARK RK KK RK RR RK EKER ER REK RRR KER RR ER ERR RRR ERE RRR ERE EREER ER 02/21/89 
3 001000 ENVIRONMENT DIVISION. 10/16/87 
4 001100 CONFIGURATION SECTION. 10/16/87 
5 01200 SOURCE-COMPUTER. IBM-AS400. 02/21/89 
6 001300 OBJECT-COMPUTER. IBM-AS400. 02/21/89 
7 001400 SPECIAL-NAMES. I-0-FEEDBACK IS FEEDBACK-AREA 10/16/87 
8 001500 OPEN-FEEDBACK IS OPEN-FBA. 10/16/87 
9 001600 INPUT-OUTPUT SECTION. 10/16/87 
10 001700 FILE-CONTROL. 10/16/87 
001800+ FJ 10/16/87 
11 001900 SELECT DBFILE ASSIGN TO DATABASE-DBFILE. 10/16/87 
12 002000 SELECT SRCICF ASSIGN TO WORKSTATION-SRCICF-SI 10/16/87 
13 002100 ORGANIZATION IS TRANSACTION 10/16/87 
14 002200 FILE STATUS IS STATUS-IND MAJ-MIN. 10/16/87 
15 002300 SELECT DFILE ASSIGN TO DATABASE-HEXDUMP. 10/16/87 
16 002400 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 10/16/87 
17. 002500 DATA DIVISION. 10/16/87 
18 002600 FILE SECTION. 10/16/87 
19 002700 FD DBFILE 10/16/87 
20 002800 LABEL RECORDS ARE STANDARD. 10/16/87 
21 002900 01 DBREC. 10/16/87 
22 003000 05 DBREC-DATA PIC X(80). 10/16/87 
23 003100 FD SRCICF 10/16/87 
24 003200 LABEL RECORDS ARE STANDARD. 10/16/87 
25 003300 01 ICFREC. 10/16/87 
26 003400 05 EVOKPGM-O. 10/16/87 
27 +=003500 10 PGMID PIC X(8). 10/16/87 
28 003600 10 PASSWD PIC X(8). 11/16/88 
29 003700 10 USERID PIC X(8). 11/16/88 
30 003800 10 LIB PIC X(8). 10/16/87 
31 003900 10 FILLER PIC X(52). 10/16/87 
32 004000 05 SNDDATA-0 REDEFINES EVOKPGM-O. 10/16/87 
33 004100 10 SNDLENGTH PIC 9(4). 10/16/87 
34 004200 10 SNDFIELD PIC X(80). 10/16/87 
35 004300 05 INVITE-O0 REDEFINES EVOKPGM-O. 02/27/89 
36 004400 10 INVLENGTH PIC 9(4). 10/16/87 
37 004500 10 INVFIELD PIC X(80). 10/16/87 
38 004600 FD DFILE 10/16/87 
39 004700 LABEL RECORDS ARE STANDARD. 10/16/87 
40 004800 01 DUMPREC. 10/16/87 
Figure 10-10 (Part 1 of 5). Source Program Example — CSFBAT (System-Supplied Formats) 
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004900 05 DUMP-MAJ-MIN PIC X(4). 
005000 05 DUMP-RECORD PIC X(400). 
005100 FD QPRINT 


005200 LABEL RECORDS ARE OMITTED. 

005300 01 PRINTREC PIC X(132). 

005400 WORKING-STORAGE SECTION. 

005500 77 STATUS-IND PIC X(2). 

005600 77 MAJ-MIN-SAV PIC X(4). 

005700 77 EOF-DBFILE-SW PIC X VALUE "0". 
005800 77 ERR-SW PIC X VALUE "0". 
005900 77 OPEN-COUNT PIC 9(1) VALUE 0. 
006000 77 LEN PIC 9(10)V9(5) COMP. 
006100 

006200 77 CMD2 PIC X(31) 

006300 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 

006400 01 OPEN-FBA. 

006500 05 FILLER PIC X(75). 

006600 05 RECS-IN-DB PIC 9(09) COMP-4. 
006700 05 FILLER PIC X(45). 

006800 01 MAJ-MIN. 

006900 05 MAJ PIC X(2). 

007000 05 MIN PIC X(2). 

007100/ 


007200 PROCEDURE DIVISION. 
007300 DECLARATIVES. 

007400 ERR-SECTION SECTION. 

007500* Fy 

007600 USE AFTER STANDARD ERROR PROCEDURE ON SRCICF. 

007700 SRCICF-EXCEPTION. 

007800* 

007900* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION 
008000« 

008100* RECOVERABLE SESSION ERROR. CLOSE ICF FILE. 


008200 IF MAJ = "03" OR MAJ = "83" 

008300 MOVE "PROGRAM STARTED AGAIN DUE TO SESSION ERROR" 

008400 TO PRINTREC 

008500 WRITE PRINTREC 

008600 MOVE "1" TO ERR-SW 

008700 GO TO EXIT-DECLARATIVES. 

008800* 

OCOBIOO Kx x KAA KKA AK KAA K EKER EKER RK EKER ERR KERR KER ERE REE RRR ERE RRR ER ER ERE REERRR 
009000* WHEN THERE IS A PERMANENT SESSION ERROR DETECTED, THE MAJOR-MINOR* 
009100* CODE IS PLACED INTO A DATABASE FILE AND THE FILE IS PRINTED IN * 


009200* HEX USING COPYFILE. * 
COI3 OD kx R KAKA ARK KARR KKK RK ERR KERR E RRR E RRR ERR EREK ERK KER ERE REE ERERRRE 
009400* 


009500 GETFBA. 

009600 OPEN OUTPUT DFILE. 

009700 MOVE MAJ-MIN TO DUMP-MAJ-MIN. 
009800 MOVE ICFREC TO DUMP-RECORD. 
009900 WRITE DUMPREC. 

010000 CLOSE DFILE. 

010100 MOVE 31 TO LEN. 

010200 CALL "QCMDEXC" USING CMD2 LEN. 
010300 MOVE "PROGRAM TERMINATED DUE TO ERROR IN ICF FILE" 
010400 TO PRINTREC. 

010500 WRITE PRINTREC. 

010600 STOP RUN. 

010700* 

010800 EXIT-DECLARATIVES. 

010900 EXIT. 

011000* 

011100 END DECLARATIVES. 

011200/ 
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10/16/87 
10/16/87 
10/16/87 
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79 


80 
81 
82 


83 
84 
85 


86 


Figure 


011300 START-PROGRAM SECTION. 


011400* 
011500 START-PROGRAM-PARAGRAPH. 
011600 Ey 

011700 OPEN INPUT DBFILE 
011800 I-0  SRCICF 
011900 QUTPUT QPRINT. 
012000* 


CWA te 


012200* THE FOLLOWING TEST IS TO ATTEMPT RECOVERY IF AN ERROR OCCURS * 


012300* WHEN OPENING THE ICF FILE. * 
O12 4 OD 4 xR KKK KAKA KKK EKER RRR ERR E RRR RRR ERR E RRR RRR ERR ER ERE REE ERERRRE 
012500* E¥ 

012600 IF ERR-SW = "1" 

012700 THEN IF OPEN-COUNT IS = 9 

012800 THEN GO TO ABNORMAL-TERMINATION 

012900 ELSE 

013000 ADD 1 TO OPEN-COUNT 

013100 PERFORM ERROR-RECOVERY-RIN 

013200 GO TO START-PROGRAM-PARAGRAPH 

013300 ELSE 

013400 MOVE © TO OPEN-COUNT. 

013500* 


O13 6 OO kx KK AAR KAA KKA KKK KER RK RRR EKER ER EKER ER ER RR EREKRRRKERRR ER ER ERE ER EER RR 


013700* EVOKE THE PROGRAM "CTDBATCL" ON THE REMOTE SYSTEM IN LIBRARY * 


013800* ICFLIB. INDICATOR IN50 IS THE EVOKE KEYWORD. * 
OL 39 OD kx K AAR KAA KKK KKK ERR RRR ERE E RRR ERK KER ERE RRR RRR RR RRR REE EREER ER 
014000* Ey 


014100 MOVE SPACES TO EVOKPGM-O. 

014200 MOVE "CTFBATCL" TO PGMID OF EVOKPGM-0. 
014300 MOVE "QSECOFR" TO PASSWD OF EVOKPGM-O. 
014400 MOVE "QSECOFR" TO USERID OF EVOKPGM-O. 
014500 MOVE "ICFLIB" TO LIB OF EVOKPGM-O. 
014600 WRITE ICFREC FORMAT IS "$$EVOKNI". 
014700 IF ERR-SW = "1" 


014800 PERFORM ERROR-RECOVERY-RTN 
014900 GO TO START-PROGRAM-PARAGRAPH. 
015000* 


O15 LOD kx KARR KAKA RK RRR RRR RRR ERE R RRR RRR ER RR ERK RRR ERE RE REE REE ERERERE 
015200* WHEN THE EVOKE OPERATION IS SUCCESSFUL, A RECORD FROM THE DATA- * 
015300* BASE FILE IS READ AND THEN SENT TO THE TARGET SYSTEM. THIS WILL * 
015400* BE REPEATED UNTIL THE END OF FILE IS REACHED ON THE DATABASE * 
015500* FILE. AT END OF FILE, THE PROGRAM DEVICE IS INVITED AND THE READ * 
015600* OPERATION IS ISSUED TO GET THE DATA FROM THE REMOTE SYSTEM. * 


O15 7 OD KKK AAR KARR KK RK ERR RRR ERR E RRR ERE KER ERE REE RRR ERR ER ER RRR ER EERE 


015800* 
015900 SEND-DATA. 

016000 [J 

016100 READ DBFILE 

016200 AT END 

016300 PERFORM INVITE-TO-SEND. 

016400 IF EOF-DBFILE-SW NOT = "1" 

016500 MOVE DBREC-DATA TO SNDFIELD OF SNDDATA-0O 
016600 MOVE +80 TO SNDLENGTH OF SNDDATA-O 
016700 PERFORM WRITE-SRCICF-RIN 

016800 GO TO SEND-DATA. 

016900* 
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10-15 


103 
104 
105 
106 
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109 
110 
111 


112 
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114 


115 


116 
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120 
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Figure 


10-16 


OL 7 OOD KAKA ARK ARK KARR KEKE RRR RRR RRR EKER ERE KER RR ER EK ERE KERR REE EKER ER ERRRE 


017100* A READ OPERATION IS ISSUED TO PROGRAM DEVICE TO CONTINUE 
017200* RECEIVING DATA FROM THE REMOTE SYSTEM UNTIL THE RCVDETACH 
017300* INDICATOR IS SET. EACH RECORD RECEIVED WILL BE PRINTED TO THE 


017400* PRINT FILE. 


* 
* 
* 
* 


O17 5 OD kx K ARK KAA KKAKK KEKE KEK RRR RRR E RRR RRR ERR RE RE RRERERER ER ER ERR ER ERER RR 


017600* 
017700 RECEIVE-DATA. 
017800* 


017900 READ SRCICF. 


018000 IF ERR-SW = "1" 

018100 PERFORM ERROR-RECOVERY-RTN 
018200 GO TO START-PROGRAM-PARAGRAPH. 
018300 IF MAJ NOT = "03" 

018400 MOVE ICFREC TO PRINTREC 

018500 WRITE PRINTREC. 

018600 IF MIN NOT = "08" 

018700 GO TO RECEIVE-DATA. 

018800* 


O1LB9OD Kx xR KKK KARR KARR KEKE KEK RRR KER RRR KERR RRR ER RRR KERR RRR ERE RRR EKER RRR RRREERE 


019000* WHEN PROCESSING IS COMPLETED, END OF JOB MESSAGE IS PRINTED. 
019100* FILES ARE CLOSED AND THE SESSION IS ENDED. 


OL IZOD Kx KAA K KAA KKA KK RK KK RK RRR KERR ERE KERR KER RRR RRR ERR KERR KERR REKERERREERREERE 


019300* 
019400 Ey 


019500 MOVE "CSFBAT HAS COMPLETED NORMALLY" TO PRINTREC. 


019600 WRITE PRINTREC. 
019700 CLOSE DBFILE 
019800 SRCICF 
019900 QPRINT. 


020000 STOP RUN. 
020100* 


O20 200k xR KKK KAA KKK KKK KERR RRR KERR RRR EK RRR KER RR ER EKER RRR RR ERE EKER ER EERER 


020300* THIS SUBROUTINE SENDS DATA TO THE REMOTE SYSTEM 


* 


O2O04 OD kx KKK AK RA KKK KKK KERR RRR KER EKER KERR RRR ER ERE KERR RRR ER KR ER ERR REE ERERER RE 


020500 WRITE-SRCICF-RTN. 


020600 Ey 


020700 WRITE ICFREC FORMAT IS "$$SENDNI". 


020800 IF ERR-SW = "1" 


020900 PERFORM ERROR-RECOVERY-RTN 
021000 GO TO START-PROGRAM-PARAGRAPH. 
021100* 

021200 ERROR-RECOVERY-RTN. 

021300* 

021400 CLOSE SRCICF 

021500 DBFILE 

021600 QPRINT. 


021700 MOVE "0" 
021800* 


TO ERR-SW. 


OZ 1IOD KAR KAA KKK AK KARR RK RRR RRR KERR RE RRR RRR RRR ERER ERE ER ERRRR 


022000* WHEN AN ERROR OCCURS ON AN ICF SESSION, INFORMATION ABOUT 
022100* THE ERROR IS PRINTED. 


* 
* 


O22 200 KKK KKK KKK ARK KK KEKE RRR ERK EKER ER EK RRR ER RRR RRR RRR ERR ER ER ERR ER ERER RE 


022300 ABNORMAL-TERMINATION. 


022400* 


022500 MOVE "CSFBAT HAS COMPLETED ABNORMALLY" 


022600 TO PRINTREC. 
022700 WRITE PRINTREC. 


022800 STOP RUN. 
022900* 
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O23 000 kx KKK A KKK KKA KK KKK RRR ERK ERR ER EK RRR ER RRR KEKE RE KER ERE ERE ER EERR 


02/21/89 


023100* WHEN END OF FILE IS DETECTED, AN INVITE OPERATION IS ISSUED TO * 02/21/89 
023200* NOTIFY THE TARGET THAT IT CAN START SENDING DATA. * 02/21/89 
O23 300 KAKA A KKK AKKA KK KEKE RRR RRR ERE ER EKER KR ER KER ER ER RRR ER ERE RE EREREREERER 02/21/89 
023400 INVITE-TO-SEND. 10/16/87 
023500* Fy 10/16/87 
125 023600 MOVE "1" TO EOF-DBFILE-SW. 10/16/87 
126 023700 MOVE +0 TO INVLENGTH OF INVITE-O. 10/16/87 
127 023800 WRITE ICFREC FORMAT IS "$$SEND". 10/16/87 
128 023900 IF ERR-SW = "1" 10/16/87 
129 024000 PERFORM ERROR-RECOVERY-RTN 10/16/87 
130 024100 GO TO START-PROGRAM-PARAGRAPH. 10/16/87 
***e** * END OF SOURCE ** * * x 
* 19 MSGID: LBLQ@650 SEVERITY: 00 SEQNBR: 002700 
Message... .: Blocking/Deblocking for file 'DBFILE' will 
be performed by compiler-generated code. 
* 38 MSGID: LBLQ650 SEVERITY: 00 SEQNBR: 004600 
Message. ...: Blocking/Deblocking for file 'DFILE' will be 
performed by compiler-generated code. 
**e*e**e** END OF MESSAGES ** * * * 
Message Summary 
Total Info(0-4) Warning(5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
2 2 0 ) 0 ) 
Source records read... .....3: 241 
Copy records read... ..... 23: 0 
Copy members processed ......: 0 
Sequence errors. .........3: 0 
Highest severity message issued ..: 0 
LBLO901 00 Program CSFBAT created in library ICFLIB. 
kk kK END OF COMPILATION ** * * * 
Figure 10-10 (Part 5 of 5). Source Program Example — CSFBAT (System-Supplied Formats) 
Target Program Batch Transfer (Example I): The a a ae ay 
: j Ax ICF FILE * 
following describes a COBOL target program batch transfer bi deca rieennGa tere ARIE ORM : 
program. Ax * 
IAI TI TI II II III IIIS IISA I IIIS IIASA SS hh 
- Ax 
Program Files: The COBOL batch transfer target program Ax FILE LEVEL INDICATORS: 
. + . Ax 
uses the following files: ‘i THOR 
Ax 
TGTICF A RCVTRNRND(15 ‘END OF DATA') 
An ICF file used to send records to and receive ie my aerael 
records from the source program. Ae 
A INDTXT(30 '30->DETACH TARG- 
DBFILE A GET PROGRAM. ') 
. ‘ Ax 
A database file that contains the records to be sent A RCVDETACH(35 ‘RECEIVED  - 
A DETACHED. ') 
to the source program. oe 
QPRINT Riles ec pretence R et cneeads, 
A printer file used to print the records received from OCR ENTR ren err er Sie Sen atid HERE Oto EEA: 
the source program. R RCVDATA 
RCVFLD 80A 
: ota R SNDDATA 
DDS Source: The DDS source used in the ICF file is illus- SNDFLD 80A 
: : , R EVOKPGM 
trated in the following example. The other files (DBFILE and Anse eiRE LTR apa 
QPRINT) are program-described and therefore requires no A 50 SECURITY (2 ee + 
3 "USERID! 
DDS. A PGMID 10A P 
A LIB 10A P 
A R ENDREC 
A R INVITE 
A 45 INVITE 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/TGTICF) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(TGTICF) ACQPGMDEV(PGMDEVB) TEXT('TARGET ICF 
FILE FOR BATCH DATA TRANSFER’) 


The command needed to define the program device entry is: 


ADDICFDEVE FILE(ICFLIB/TGTICF) PGMDEV(PGMDEVB) 
RMTLOCNAME (*REQUESTER) 
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This example acquires all sessions at the beginning of the 
program. For performance considerations, you may not want 
to acquire sessions until they are actually needed in the 
program. 


Program Explanation: The following describes the struc- 
ture of the program examples illustrated in Figure 10-11 on 
page 10-19 and Figure 10-12 on page 10-23. The ICF file 
used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference numbers 
in the explanation below correspond to the numbers in the 
following program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the use of user- 
defined formats and system-supplied formats. 


Differences between the first and second example are docu- 
mented as notes in each of the descriptions. 


EF¥_ This section identifies the files used in the program. 
TGTICF is the ICF file used to send records to the 
source program. 


This section also contains declarations of I/O variables, 
work areas, and constants needed. MAJ-MIN contains 
the major/minor return code from the I/O feedback 
area. 


Note: In the program using system-supplied formats, 
the input records for TGTICF are explicitly coded in the 
program since TGTICF is now treated as a program- 
described file. The system-supplied file, QICDMF, can 
be used instead of TGTICF. Using the system- 
supplied file can be done by specifying QICDMF in the 
file specification, or by using an OVRICFF command to 
change the file name from TGTICF to QICDMF. The 
OVRICFF command can also be used to change the 
ACQPGMDEV parameter of the file. 


Hs The program defines the error handling for the 
program. If an error occurs, the program writes the fol- 
lowing message to the printer file: 


CTDBAT HAS COMPLETED ABNORMALLY 

The session is released. 

Note: In the program using system-supplied formats, 
the program name is CTFBAT. 


The program opens the files that are going to be used 
as follows: 
DBFILE 
The database file used as input for transmit- 
ting to the source program 
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QPRINT 
The printer file used as output for records 
received 


TGTICF 
The ICF file used to receive data from and 
send data to the source program 


Because the ICF file was created using the 
ACQPGMDEV parameter, the program device 
is automatically acquired when the file is 
opened. Therefore, no acquire operation is 
coded in the program. 


Data is read from the program device (TGTICF file). 


If an error occurs on the read (major return code 
greater than '03'), control passes to J. Otherwise if 
data was received (major return code not = '03'), then 
the data is written to the printer file (QPRINT). 


Data records are read until the change-direction indi- 
cator is received from the source program. When 
change direction is received, indicator 15 is set on, as 
defined by the RCVTRNRND keyword in the DDS for 
the ICF file, and control is passed to J. 


Note: In the program using system-supplied formats, 
the minor return code of '00' is checked to verify 
whether change direction is received. 


The database file is read and the records sent to the 
source program until the end of the database file. At 
end-of-file, the program passes control to Kg. 


If it is not the last record, then the data is written to the 
program device using the format SNDDATA, and the 
next database record is read. If an error occurs on the 
write operation, the program goes to EJ anda 
message is printed. 


Note: In the program using system-supplied formats, 
the $$SENDNI format is used instead of the user- 
defined SNDDATA format. 


This routine issues a detach request to the program 
device using format ENDREC. Indicator 30 is associ- 
ated with the DETACH keyword. If an error occurs, the 
program goes to — and a message is printed. 


Note: In the program using system-supplied formats, 
the $$SENDET format is used instead of the user- 
defined ENDREC format. 


After the detach request has been sent, the following 
message is written to the printer file: 

CTDBAT HAS COMPLETED NORMALLY 

The files are closed. The program device is automat- 


ically released as a result of the close operation, and 
the program ends. 


Note: In the program using system-supplied formats, 
the program name is CTFBAT. 


Program 
Library .. 
Source file . 
Library .. 
Source member 


Generation severity level 
Text 'description' 


CTDBAT 
ICFLIB 

QICFPUB 
ICFLIB 

CTDBAT 

¢. oo8. Goad 29 


Source listing options .......: *SQURCE 
Generation options. ........:  *NONE 
Message limit: 

Number of messages ........: + *NOMAX 

Message limit severity ......: 29 
Print fil@ oe ese a. Sh 8 QSYSPRT 

MET AVAY ©” oes ibs Sen St coke ated ciocechs teak cap etn *LIBL 
EIPS: TiAQGING: | os) eo oe ee a 
SAAS TAGGING ie. se: ee fe ee ee aes ce *NOFLAG 
Flagging severity .........: 0 
Replace program ..........3: *YES 
Target release... 1... 2... 23 *CURRENT 
User profile. 2% 66 see ee et *USER 
Authority ice ce ape gow Se eS *LIBCRTAUT 
COMpPITe rs es eR ee IBM AS/400 COBOL/400 


1 Q00100 IDENTIFICATION DIVISION. 


2 000200 PROGRAM-ID. 


CTDBAT. 


02/21/89 17:51:20 


cobol batch file transfer using dds (target) 


*NOFIPS *NOSEG *NODEB *NOOBSOLETE 


OQOO3 OD kx K KKK KAA KKA KR K EKER ERK ERR ERK RRR KERR RE RER RR ERERER ER ER ERE ER ERER RR 
THIS TARGET PROGRAM IS EVOKED BY THE SOURCE PROGRAM AND * 
RECEIVES RECORDS FROM IT. WHEN THE SOURCE PROGRAM IS DONE * 
SENDING DATA, THIS PROGRAM SENDS ITS OWN RECORDS UNTIL IT IS” * 


000400* 
000500« 
000600« 
000700« 
000800« 


DONE. 
PROGRAM AND ENDS ITS SESSION AND JOB. 


WHEN IT IS DONE, IT SENDS A DETACH REQUEST TO THE SOURCE* 


* 


OQOOQOD Kx x KAKA KAKA KK RAK KEK RRR KERR RRR RRR RRR KERR RE RE RRKRERER ER ER REREREREER RR 
001000 ENVIRONMENT DIVISION. 
001100 CONFIGURATION SECTION. 


3 

4 

5 01200 SOURCE-COMPUTER. 
6 001300 OBJECT-COMPUTER. 
7 001400 SPECIAL-NAMES. 

8 

9 


001500 


IBM-AS400. 
IBM-AS400. 


001600 INPUT-OUTPUT SECTION. 
001700 Ey 
10 001800 FILE-CONTROL. 


D. 


I-0-FEEDBACK IS FEEDBACK-AREA 
OPEN-FEEDBACK IS OPEN-FBA. 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


AKRAAAAKANKAAKAAA 
rPrerrrrrrrrrrsye 


11 001900 SELECT DBFILE ASSIGN TO DATABASE-DBFILE. 

12 002000 SELECT TGTICF ASSIGN TO WORKSTATION-TGTICF-SI 

13 002100 ORGANIZATION IS TRANSACTION 

14 002200 FILE STATUS IS STATUS-IND MAJ-MIN. 

15 002300 SELECT DFILE ASSIGN TO DATABASE-HEXDUMP. 

16 002400 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 

17, 002500 DATA DIVISION. 

18 002600 FILE SECTION. 

19 002700 FD DBFILE 

20 002800 LABEL RECORDS ARE STANDARD. 

21 002900 01 DBREC. 

22 003000 05 DBREC-DATA PIC X(80). 

23 003100 FD TGTICF 

24 003200 LABEL RECORDS ARE STANDARD. 

25 003300 01 ICFREC. 

26 003400 COPY DDS-ALL-FORMATS OF TGTICF. 

27 +000001 05 TGTICF-RECORD PIC X(80). 
+000002* INPUT FORMAT:RCVDATA FROM FILE TGTICF 
+000003* 

28 +000004 05 RCVDATA-I REDEFINES TGTICF-RECO 

29 +000005 06 RCVFLD PIC X(80). 
+000006* OUTPUT FORMAT:RCVDATA FROM FILE TGTICF 
+000007* 

30 +000008 05 RCVDATA-O REDEFINES TGTICF-RECO 

31 +000009 06 RCVFLD PIC X(80). 
+000010* INPUT FORMAT:SNDDATA FROM FILE TGTICF 
+000011* 

32 +000012 05 SNDDATA-I REDEFINES TGTICF-RECO 

33 +000013 06 SNDFLD PIC X(80). 

Figure 10-11 (Part 1 of 5). Target Program Example — CTDBAT (User-Defined Formats) 
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34 
35 


36 


38 


Figure 
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+000014* OUTPUT FORMAT: SNDDATA 


+000015* 
+000016 
+000017 
+000018* 
+000019* 
+000020* 
+000021* 
+000022* 
+000023 
+000024 
+000025 
+000026* 
+000027* 
+000028* 
+000029* 
+000030* 
+000031* 
+000032* 
+000033* 
+000034* 
+000035* 
+000036* 
+000037* 
003500 
003600 
003700 
003800 
003900 
004000 
004100 
004200 
004300 
004400 
004500 
004600 
004700 
004800 
004900 
005000 
005100 
005200 
005300 
005400 
005500 
005600 
005700 
005800 
005900 
006000 
006100 
006200/ 


OUTPUT FORMAT: EVOKPGM 


05 SNDDATA-0 
06 SNDFLD 
INPUT FORMAT: EVOKPGM 


05 EVOKPGM-I 


FROM FILE TGTICF OF LIBRARY 


REDEFINES TGTICF-RECORD. 
PIC X(8Q). 
FROM FILE TGTICF OF LIBRARY 


REDEFINES TGTICF-RECORD. 
FROM FILE TGTICF OF LIBRARY 


05 EVOKPGM-0 REDEFINES TGTICF-RECORD. 
06 PGMID PIC X(10). 
06 LIB PIC X(10). 


INPUT FORMAT: ENDREC FROM FILE TGTICF OF LIBRARY 


05 ENDREC-I REDEFINES TGTICF-RECORD. 


OUTPUT FORMAT: ENDREC FROM FILE TGTICF OF LIBRARY 


05 ENDREC-0 REDEFINES TGTICF-RECORD. 


INPUT FORMAT: INVITE FROM FILE TGTICF OF LIBRARY 


05 INVITE-I REDEFINES TGTICF-RECORD. 


OUTPUT FORMAT: INVITE FROM FILE TGTICF OF LIBRARY 


FD 


01 


FD 


01 
Wo 


01 


01 


05 INVITE-0 
DFILE 
LABEL RECORDS ARE STANDARD. 
DUMPREC. 
05 DUMP-MAJ-MIN 
05 DUMP-RECORD 
QPRINT 
LABEL RECORDS ARE OMITTED. 
PRINTREC PIC X(132). 
RKING-STORAGE SECTION. 
MAJ-MIN-SAV 
STATUS-IND 
INDON 
INDOFF 
LEN 


CMD2 


PIC 
PIC 


PIC 
PIC 
PIC 
PIC 
PIC 


REDEFINES TGTICF-RECORD. 


X(4). 
X(80). 


X(4). 

X(2). 

1 VALUE B"1". 

1 VALUE B"O". 
9(10)V9(5) COMP 


VALUE 0. 


PIC 


X(31) 


VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 


CMNF-INDIC-AREA. 
05 CMNF-INDIC 


OPEN-FBA. 

05 FILLER 

05 RECS-IN-DB 
05 FILLER 
MAJ-MIN. 

05 MAJ 

05 MIN 


006300 PROCEDURE DIVISION. 
006400 DECLARATIVES. 

006500 ERR-SECTION SECTION. 
006600 Eq 


006700« 
006800 


007000« 
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PIC 


1 OCCURS 99 TIMES 


INDICATOR 1. 


PIC 
PIC 
PIC 


PIC 
PIC 


X(75). 
9(09) COMP-4. 
X(45). 


X(2). 
X(2). 


USE AFTER STANDARD ERROR PROCEDURE ON TGTICF. 
006900 TGTICF-EXCEPTION. 
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ICFLIB 


ICFLIB 


ICFLIB 


ICFLIB 


ICFLIB 


ICFLIB 


ICFLIB 


AAAAKAAKRAKRAKRANANANAANANANAAAAA 


rPrerrrrrrrrrrrrrrrrrrrrrse 
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L-FMT 
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Figure 


78 


85 


88 


89 
90 


Figure 


OO7 LOD Kx KR ARK KAA KARR RK RR RK RRR KERR KER ERR RRR ERE ER EKER KR ERE RRR ERE ER EERRE 


007200* GET INFORMATION FROM THE MAJOR-MINOR CODE AND PLACE IT INTO * 
007300* A DATABASE FILE. THEN PRINT THE FILE IN HEX USING COPYFILE. * 
OO 7 AOQ KKK AKA KKK KKK AKER KKK KKK KKK KKK KKK KKK KKK KKK KERR EKER KERRIER ERE RR EK 
007500* 


007600 GETFBA. 

007700 MOVE "CTDBAT HAS COMPLETED ABNORMALLY" TO PRINTREC. 
007800 WRITE PRINTREC. 

007900 OPEN OUTPUT DFILE. 

008000 MOVE MAJ-MIN TO DUMP-MAJ-MIN. 
008100 MOVE ICFREC TO DUMP-RECORD. 
008200 WRITE DUMPREC. 

008300 CLOSE DFILE. 

008400 MOVE 31 TO LEN. 

008500 CALL "QCMDEXC" USING CMD2 LEN. 
008600 STOP RUN. 

008700* 

008800 EXIT-DECLARATIVES. 

008900 EXIT. 

009000* 

009100 END DECLARATIVES. 

009200/ 


10-11 (Part 3 of 5). Target Program Example — CTDBAT (User-Defined Formats) 


009300 START-PROGRAM SECTION. 
009400 START-PROGRAM-PARAGRAPH. 


009500* 

009600 OPEN OUTPUT QPRINT 
009700 1-0  TGTICF 
009800 INPUT DBFILE. 
009900* 


(CNR et re er ee ee 


010100* DATA CONTINUES TO BE RECEIVED FROM THE PROGRAM DEVICE UNTIL THE * 


010200* RCVTRNRND INDICATOR IS SET. EACH RECORD RECEIVED IS PRINTED TO * 
010300* THE PRINT FILE. * 
OLO4 OD kx xR KKK KARR KARR RK K KEKE RRR R EKER ERE RRR RR ERE RRR RRR ERE RE RE EREREREER RE 
010500* 

010600 RECEIVE-DATA. 

010700+ Eq 

010800 READ TGTICF INDICATORS ARE CMNF-INDIC-AREA. 

010900 IF MAJ NOT = "03" 

011000 MOVE ICFREC TO PRINTREC 

011100 WRITE PRINTREC. 

011200» Ey 

011300 IF CMNF-INDIC(15) NOT = INDON 

011400 GO TO RECEIVE-DATA. 

011500* 


OL LO OO kx xR KKK KAKA KK RRR RRR RRR ERE ER ERR RRR ER ERE REE RRR ERR ER ER ERE ER EERE 


011700* RECORD IS READ FROM THE DATABASE FILE AND SENT TO THE SOURCE * 


011800* PROGRAM. DATA TRANSMISSION CONTINUES UNTIL END OF FILE IS * 
011900* DETECTED ON THE DATABASE FILE. AT THIS TIME, A DETACH REQUEST * 
012000* IS SENT TO THE SOURCE PROGRAM. * 
CNWARCC ete ee 
012200* 

012300 SEND-DATA. 

012400* f¥ 


012500 READ DBFILE AT END GO TO SIGNAL-DETACH. 

012600 WRITE ICFREC FROM DBREC FORMAT IS "SNDDATA" 

012700 INDICATORS ARE CMNF-INDIC-AREA. 

012800 GO TO SEND-DATA. 

012900* 

O13 OOD * x KKK AK KAKA KKK KEK EKER KK ERR E RRR ERE KER RRR RRR RRR ERE ERERERER ER ERRRE 
013100* SIGNAL DETACH TO THE SOURCE PROGRAM. * 
O13 200 kK KKK KAA KKA KK RAKE RRR RRR ERE ER EK RRR KER ERE RRR RRR ER ERR REE REE ERERERRR 
013300* 

013400 SIGNAL-DETACH. 

013500* 

013600 MOVE INDON TO CMNF-INDIC(30). 

013700 WRITE ICFREC FORMAT IS "ENDREC" 

013800 INDICATORS ARE CMNF-INDIC-AREA. 
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10-21 


91 
92 
93 
94 
* 19 
* 26 
* 26 
* 26 
* 26 
* 26 
* 39 
* 67 
Total 
8 
Source 


O13 9 OD KKK KKK AKA KK KEKE KEK RRR ERE E RRR RR KK RR RRR REE RRR ERE RRR EKER RRR RR REERE 
014000* WHEN THE END OF FILE IS REACHED, AN EOJ MESSAGE IS PRINTED * 
014100* AND THE PROGRAM ENDS. 


OLA 200 kx xR KKK KAA KKA KKK ERR RRR RRR REK ERR ER RRR RRR RRR KERR REE RRR RE RERERRREERE 


014300* Fy 


014400 MOVE "CTDBAT HAS COMPLETED NORMALLY" TO PRINTREC 
014500 WRITE PRINTREC. 
014600 CLOSE DBFILE 


014700 
014800 


TGTICF 
QPRINT. 


014900 STOP RUN. 


MSGID: LBLQ650 
Message... 

be performed 
MSGID: LBLQ600 
Message . 


MSGID: LBL0600 


Message . 


MSGID: LBL0O600 


Message . 


MSGID: LBL0600 


Message . 


MSGID: LBL0O600 


Message . 


MSGID: LBL0650 


Message... 
performed by 
MSGID: LBLO335 


Message. ... 


paragraph or 


Info(0-4) 
3 
records read . 


Copy records read. . 


Copy members processed 


Sequence errors... 
Highest severity message issued. . : 
LBLO901 00 Program CTDBAT created in library ICFLIB. 


kK KKK END 
SEVERITY: 00 SEQNBR: 
ocking for file 'DBFILE' will 
by compiler-generated code. 
SEVERITY: 10 SEQNBR: 
ds found for format EVOKPGM. 


Blocking/Deb 


o INPUT fie 


o INPUT fie 


o INPUT fie 


SEVERITY: 10 SEQNBR: 


* 


OF SOURCE ** * * * 


002700 


003400 


003400 


ds found for format ENDREC. 


SEVERITY: 10 SEQNBR: 
7 o OUTPUT fields found for format ENDREC. 
SEVERITY: 10 SEQNBR: 


003400 


003400 


ds found for format INVITE. 


SEVERITY: 10 SEQNBR: 
: o OUTPUT fields found for format INVITE. 


003400 


SEVERITY: 00 SEQNBR: 003500 


Blocking/Deb 


ocking for file 'DFILE' will be 


compiler-generated code. 
SEVERITY: 00 SEQNBR: 


: Empty paragraph or section precedes 'GETFBA' 


section. 
kK kK KKK END 


Warning (5--19) 


kk KKK END 


10 


OF 


OF 


007600 


MESSAGES ** * * * 
Message Summary 
Error (20-29) Severe (30-39) 


) ) 


COMPILATION 


Terminal (40-99) 


kK kK KKK 
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) 


02/21/89 
02/21/89 
02/21/89 
02/21/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 


Program ... 
Library .. 
Source file . 
Library .. 
Source member 
Generation sev 
Text 'descript 
Source listing 
Generation opt 
Message limit: 
Number of me 
Message limi 
Print file. . 
Library .. 
FIPS flagging 


Sy Utne ey Sno eee sets: COOREBAT 

St oat EEE Wa en Hh aee eS a ICFLIB 
fee Bho le ag ek SO QTERPUB 
wget e He Gee eS ICFLIB 


a Be ec tar She te he ah were > — ACTFBAT 02/27/89 09:38:46 


erity level .....: 29 


ion’. ....... . 2 Cobol batch file transfer using $$FORMAT (target) 


options ....... :  *SQURCE 
jons......... :  *NONE 
ssages ........ 3: *NOMAX 
t severity. .....: 29 

oa ieee et eed Gate dts 2OSYMSPRT. 
Ra tak st ectee uc ests Wt coos setae the *LIBL 


soe eee ew ee ee et) *NOFIPS *NOSEG *NODEB *NOOBSOLETE 


SAA flagging. ......... +... : + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release. . 2... . 2... 3) *CURRENT 
User profile. ........... :  *USER 
Authority ............. : *LIBCRTAUT 
Compiler. .......... 4. 2 IBM AS/400 COBOL/400 
1 Q00100 IDENTIFICATION DIVISION. 02/21/89 
2 000200 PROGRAM-ID. CTFBAT. 02/21/89 
OQOO3 0D kx K KKK KARA KKK K EKER ER KK ERR E RRR RRR KER ERE RRR ERE KER RRR REE REE ER EER RR 02/22/89 
000400* THIS TARGET PROGRAM IS EVOKED BY THE SOURCE PROGRAM AND * 02/22/89 
000500* RECEIVES RECORDS FROM IT. WHEN THE SOURCE PROGRAM IS DONE * 02/22/89 
000600* SENDING DATA, THIS PROGRAM SENDS ITS OWN RECORDS UNTIL IT IS”) * 02/22/89 
000700* DONE. WHEN THIS PROGRAM IS DONE, IT SENDS A DETACH REQUEST TO * 02/22/89 
000800* THE SOURCE PROGRAM AND ENDS ITS SESSION AND JOB. * 02/22/89 
OQOOQOD Kaa KAA KK KAKA AKER ERR RRR KERR RRR RRR RRR KERR ERE REE RRR ERE RE RE EREREEREER RE 02/22/89 
3 001000 ENVIRONMENT DIVISION. 10/16/87 
4 001100 CONFIGURATION SECTION. 10/16/87 
5 01200 SOURCE-COMPUTER. IBM-AS400. 02/21/89 
6 001300 OBJECT-COMPUTER. IBM-AS400. 02/21/89 
7 001400 SPECIAL-NAMES. I-0-FEEDBACK IS FEEDBACK-AREA 10/16/87 
8 001500 OPEN-FEEDBACK IS OPEN-FBA. 10/16/87 
9 001600 INPUT-OUTPUT SECTION. 10/16/87 
001700* 10/16/87 
10 001800 FILE-CONTROL. 10/16/87 
11 001900 SELECT DBFILE ASSIGN TO DATABASE-DBFILE. 10/16/87 
12 002000 SELECT TGTICF ASSIGN TO WORKSTATION-TGTICF-SI 10/16/87 
13 002100 ORGANIZATION IS TRANSACTION 10/16/87 
14 002200 FILE STATUS IS STATUS-IND MAJ-MIN. 10/16/87 
15 002300 SELECT DFILE ASSIGN TO DATABASE-HEXDUMP. 10/16/87 
16 002400 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 10/16/87 
17. 002500 DATA DIVISION. 10/16/87 
18 002600 FILE SECTION. 10/16/87 
19 002700 FD DBFILE 10/16/87 
20 002800 LABEL RECORDS ARE STANDARD. 10/16/87 
21 002900 01 PREC. 10/16/87 
22 003000 05 PREC-DATA PIC X(80). 10/16/87 
23 003100 FD TGTICF 10/16/87 
24 003200 LABEL RECORDS ARE STANDARD. 10/16/87 
25 003300 01 ICFREC. 10/16/87 
26 003400 05 SNDDATA-O. 10/16/87 
27 ~=003500 10 SNDLENGTH PIC 9(4). 10/16/87 
28 003600 10 SNDFIELD PIC X(80). 10/16/87 
29 003700 05 ENDREC-0 REDEFINES SNDDATA-O. 10/16/87 
30 003800 10 ENDLENGTH PIC 9(4). 10/16/87 
31 003900 10 FILLER PIC X(80). 10/16/87 
32 004000 FD DFILE 10/16/87 
33 004100 LABEL RECORDS ARE STANDARD. 10/16/87 
34 004200 01 DUMPREC. 10/16/87 
35 004300 05 DUMP-MAJ-MIN PIC X(4). 10/16/87 
36 004400 05 DUMP-RECORD PIC X(80). 10/16/87 
37 004500 FD QPRINT 10/16/87 
38 004600 LABEL RECORDS ARE OMITTED. 10/16/87 
39 004700 01 PRINTREC PIC X(132). 10/16/87 
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10-23 


67 


68 


Figure 


10-24 


004800 WORKING-STORAGE SECTION. 
004900 77 MAJ-MIN-SAV 

005000 77 STATUS-IND 

005100 77 INDON 

005200 77 INDOFF 


005300 77 LEN 


005400 


PIC X(4). 

PIC X(2). 

PIC 1 VALUE B"1". 
PIC 1 VALUE B"O". 
PIC 9(10)V9(5) COMP 
VALUE 0. 


005500 77 CMD2 PIC X(31) 

005600 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 

005700 01 OPEN-FBA. 

005800 05 FILLER PIC X(75). 

005900 05 RECS-IN-DB PIC 9(09) COMP-4. 
006000 05 FILLER PIC X(45). 

006100 01 MAJ-MIN. 

006200 05 MAJ PIC X(2). 

006300 05 MIN PIC X(2). 

006400/ 


006500 PROCEDURE DIVISION. 
006600 DECLARATIVES. 
006700 ERR-SECTION SECTION. 


006800 Eq 
006900* 


007000 USE AFTER STANDARD ERROR PROCEDURE ON TGTICF. 


007100 TGTICF- 


007200* 


EXCEPTION. 


OO7 300K xR KAKA KAKA KK KEKE RRR RRR ER RRR KEKE RRR ER RR ER ER RRR RRR RR E REE RERERERRRE 


007400* GET INFORMATION FROM THE MAJOR-MINOR CODE AND PLACE IT INTO 


007500* A DATABASE FILE. THEN PRINT THE FILE IN HEX USING COPYFILE. 


* 
* 


OO7 GOD KAA KAA KK KAKA AKER EKER RRR ERR ERREK RRR KER RRR RRR RRR ERR ER ER ERR ER REER ER 


007700* 
007800 GETFBA. 


007900 MOVE "CTFBAT HAS COMPLETED ABNORMALLY" TO PRINTREC. 
008000 WRITE PRINTREC. 
008100 OPEN OUTPUT DFILE. 


008200 MOVE MAJ-MIN TO DUMP-MAJ-MIN. 
008300 MOVE ICFREC TO DUMP-RECORD. 


008400 WRITE DUMPREC. 
008500 CLOSE DFILE. 
008600 MOVE 31 TO LEN. 


008700 CALL "QCMDEXC" USING CMD2 LEN. 


008800 STOP RUN. 


008900« 


009000 EXIT-DECLARATIVES. 
009100 EXIT. 


009200* 


009300 END DECLARATIVES. 


009400/ 


009500 START-PROGRAM SECTION. 
009600 START-PROGRAM-PARAGRAPH. 


009700* 


009800 OPEN OUTPUT QPRINT 


009900 
010000 
010100* 


1-0 TGTICF 
INPUT DBFILE. 


(CNROVAC (hte ee ee 


010300* DATA CONTINUES TO BE RECEIVED FROM THE PROGRAM DEVICE UNTIL THE 
010400* RCVTRNRND INDICATOR IS SET. 


010500* THE PRINT FILE. 


OLOB OD Kx xR ARK KAA KKK AKER EKER RRR ERE ER ERR RRR ER RRR RRR RRR ER RRR REE REE ERERERR 


010700* 


010800 RECEIVE-DATA. 


010900 Ey 


011000 READ TGTICF. 


011100 IF 
011200 
011300 
011400» FE 
011500 IF 
011600 
011700* 
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MAJ NOT = "03" 


MOVE ICFREC TO PRINTREC 


WRITE PRINTREC. 


MIN = "O01" THEN 
GO TO RECEIVE-DATA. 


ICF Programming V4R1 


EACH RECORD RECEIVED IS PRINTED TO 


* 
* 
* 


10/16/87 
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10/16/87 
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10/16/87 
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10/16/87 
10/16/87 
02/27/89 
02/27/89 
02/27/89 
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02/27/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
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10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 


OL 1800 & xx KAA K KARR KK RRR KEKE RR KER RR ER EK ERK RRR ER ER RRR ERE RE RE RRERERERRRE 


02/22/89 


011900* RECORD IS READ FROM THE DATABASE FILE AND IS SENT TO THE SOURCE * 02/22/89 
012000* PROGRAM. DATA TRANSMISSION CONTINUES UNTIL END OF FILE IS * 02/22/89 
012100* DETECTED ON THE DATABASE FILE. AT THIS TIME, A DETACH SIGNAL IS * 02/22/89 
012200* SENT TO THE SOURCE PROGRAM. * 02/22/89 
O12 300 kx KKK AK KAKA KKK ERE R RK ERE E RRR RR RR EREREREK RRR ERE RE RE ERREKEREREER RR 02/22/89 
012400* 10/16/87 
012500 SEND-DATA. 10/16/87 
012600* 10/16/87 
75 012700 READ DBFILE AT END GO TO SIGNAL-DETACH. 10/16/87 
77 012800 MOVE PREC TO SNDFIELD OF SNDDATA-O. 10/16/87 
78 012900 MOVE +80 TO SNDLENGTH OF SNDDATA-O. 10/16/87 
79 013000 WRITE ICFREC FORMAT IS "$$SENDNI". 10/16/87 
80 013100 GO TO SEND-DATA. 10/16/87 
013200* 10/16/87 
O13 300 kx K KKK KAA KKA RRR KER EKER KKK EKER RK ERE ER ER ERE RRRRERERERERERERERERRRE 02/22/89 
013400* SIGNAL DETACH TO THE SOURCE PROGRAM. * 02/22/89 
O13 500 kx KARR ARK KARR KEKE KEK RRR KERR RE REK RRR RR ERE REE RRR RRR ERE ERE ER EER RR 02/22/89 
013600* 10/16/87 
013700 SIGNAL-DETACH. 10/16/87 
013800* fq 10/16/87 
81 013900 MOVE SPACES TO ENDREC-O. 10/16/87 
82 014000 MOVE +@ TO ENDLENGTH OF ENDREC-0. 10/16/87 
83 014100 WRITE ICFREC FORMAT IS "$$SENDET". 10/16/87 
OLA 200 kx K KKK KAA KKA RK RK EKER ERK EKER ER ER RRR ERE ER ERR RRR ER RR ER ER ERE ER EER ER 02/22/89 
014300* WHEN THE END OF FILE IS REACHED, AN EQJ MESSAGE IS PRINTED AND « 02/22/89 
014400* THE PROGRAM ENDS. * 02/22/89 
OLA 5 OD kx x RAK KKK A KKK K RARER RK R RRR ERR ER ERR RRR ERE RE RRR RRR ERR ERE RRR ER REER RE 02/22/89 
014600* Ey 10/16/87 
84 014700 MOVE "CTFBAT HAS COMPLETED NORMALLY" TO PRINTREC 10/16/87 
85 014800 WRITE PRINTREC. 10/16/87 
86 014900 CLOSE DBFILE 10/16/87 
015000 TGTICF 10/16/87 
015100 QPRINT. 10/16/87 
87 015200 STOP RUN. 10/16/87 


eee ee END OF 


* 19 MSGID: LBLQ@650 SEVERITY: 00 SEQNBR: 002700 
Message... . 3: 
be performed by compiler-generated code. 
* 32 MSGID: LBLQ650 SEVERITY: 00 SEQNBR: 004000 
Message... .: 
performed by compiler-generated code. 
* 57 MSGID: LBLQ@335 SEVERITY: 00 SEQNBR: 007800 
Message... .: 
paragraph or section. 
KK KKK END OF 
Message Summary 
Error (20-29) 
) 


Total Info(0-4) Warning(5-19) 


3 3 0 
Source records read... .....3: 152 
Copy records read... ......: @ 
Copy members processed ......: @ 
Sequence errors ..........: @ 
Highest severity message issued ..: 0 


LBLO901 00 Program CTFBAT created in library ICFLIB. 
** ee * END OF 


SOURCE 


MESSAGES 


Severe (30-39) 
0 


COMPILATION 


Kk KKK 


Blocking/Deblocking for file 'DBFILE' will 


Blocking/Deblocking for file 'DFILE' will be 


Empty paragraph or section precedes 'GETFBA' 


kK Rk KKK 


Terminal (40-99) 
0 


kK kK KKK 


Figure 10-12 (Part 3 of 3). Target Program Example — CTFBAT (System-Supplied Formats) 


Multiple-Session Inquiry (Example Il) 


This example illustrates an interactive inquiry application that 
communicates with multiple ICF sessions. A source AS/400 
system program accepts inquiries from a display device and 
sends a request to one of four AS/400 systems. The source 
program communicates with the display device through a 
display file, and with the four remote systems through a 
single ICF file. 


The purpose of this example is to show multiple sessions 
from a single ICF file. The source program communicates 
with four sessions. From the viewpoint of each of the four 
target programs, there is only one session (with the 
requesting program device). Therefore, the target programs 
do not require any unique logic to support the multiple- 
session source. 


Both the source program and the target program are 
described. The same target program is evoked in each of 
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the four separate remote systems. Therefore, only one Transaction Flow of the Multiple-Session Inquiry 

target program is shown in the programming example. (Example Il): The program shown in Figure 10-13 is 
started from a display station, and both the display and the 
ICF file are opened. CIWSOO0 is the *REQUESTER device, 
acquired when the display file opens. CIWSO0 is acquired 
because DEV(*REQUESTER) was specified when the 
display file was created. Since the ICF file was created with 
ACQPGMDEV(*NONE), no ICF program devices are 
acquired during open processing. 


Display 


Station 


Remote AS/400 System 


Display File 
CIWS00 


Open 


Remote AS/400 System 


Open 
i ICFOO 


Program 


ICFO1 


ICF02 


ICFO3 
ICF File 


R te AS/400 System 
Local AS/400 System oe 


Remote AS/400 System 


RSLS199-4 


Figure 10-13. Program Starts at Display Station 
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All other program devices must be explicitly acquired by the 
program, as shown in Figure 10-14. 


Display 


Station 


Remote AS/400 System 


Display File 
CIWS00 


Remote AS/400 System 


ICFOO 


Program ACQ 


> ICF01 


ACQ 
ICFO2 

ACQ 
ICFO3 
ICF File 


Remote AS/400 System 
Local AS/400 System : 


Remote AS/400 System 


RSLS651-4 


Figure 10-14. Program Devices Explicitly Acquired 
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All target programs are started with the evoke, as shown in 


Figure 10-15. 
Display 
Station 
Remote AS/400 System 
ICF Program Database 
>>| . 
File File 
Display File 
CIWSO0O 
Remote AS/400 System 
Write Evoke 
a 1 ICFOO 
rogram ‘ 
9 Write Evoke ICF Program Database 
ICFO1 >| ‘ F 
File File 
Write Evoke 
| ICFO2 
Write Evoke 
-—__—*} KS F03 
ICF File 
Remote AS/400 System 
Local AS/400 System 
ICF Program Database 
>| 
File File 
Remote AS/400 System 
ICF Program Database 
>| 
File File 


Figure 10-15. Evoke Starts Target Programs 
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rodca 


RSLS652-4 


The source program uses a specific program device name. 
Each target program uses an ICF file with a program device 
name that is associated with the requesting program device. 
The target program’s only session is the one used to com- 
municate with the source program. The ICF file on the 


Display 


Station 


Write 


Program 


[>> CIWSOO 


Display File 


with the requesting program device specified on the 
ACQPGMDEV parameter, the requesting program device is 
acquired when the file is opened. The main menu is written 
to the display station on the local system, and the program 


waits for a request from the display station, as shown in 
remote system must be opened by the COBOL language Figure 10-16. 
support using the open operation. Since the file was created 


Remote AS/400 System 


ICFOO 


ICFO1 


ICFO2 


ICFO3S 


ICF File 


Local AS/400 System 


Figure 10-16. Main Menu Written to Display Station 


ICF Program Database 

File File 
Remote AS/400 System 

ICF Program Database 

File File 


om Cc 


Remote AS/400 System 


CT 


ICF Program Database 

File File 
Remote AS/400 System 

ICF Program Database 

File File 


D 
0) 
r 
0) 
D 
a 
o 
a 
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The source program sends an inquiry request to one of the 
remote systems based on the request made from the display 
station, as shown in Figure 10-17. 


Remote AS/400 System 


Program 


Display File 


File 


Program 


Database 


File 


Remote AS/400 System 


ICF 


CIWSOO 
ICFOO 
Write 
with 
ja EE 
ICFO1 
Invite 
ICFO2 
ICFOS 
ICF File 


Local AS/400 System 


File 


Read 


Program 


Database 


File 


Remote AS/400 System 


File 


Program 


Database 


File 


Remote AS/400 System 


ICF 


File 


Program 


Database 


File 


ooad 


Figure 10-17. Program Sends Inquiry Request to Remote System 
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RSLs654-4 


The target program responds to the inquiry by sending a 


reply, as shown in Figure 10-18. 


Display 


Station 


Remote AS/400 System 


Program Read 


Display File 


CIWS00 


ICFOO 


cr 


ICFO1 +} 


ICF02 


ICFO3 


ICF File 


Local AS/400 System 


Figure 10-18. Target Program Sends a Reply 


ICF Program Database 

File File 
Remote AS/400 System 

ICF Write | Program | Read | Database 

File . File 
Remote AS/400 System 

ICF Program Database 

File File 
Remote AS/400 System 

ICF Program Database 

File File 


mood 


RSLS655-4 
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The program sends a detach request and ends the session 
when function key 1 is pressed (while the main inquiry menu 
is present), as shown in Figure 10-19. 


Source Program Multiple-Session Inquiry (Example 
Il): The following describes a COBOL source program 
multiple-session inquiry. 


Program Files: The COBOL multiple session source 
program uses the following files: 


CMNFIL 
An ICF file used to send records to and receive 
records from the target program. 


DSPFIL 
A display file used to enter requests that are to be 
sent to the target program. 


QPRINT 
A printer file used to print error messages resulting 
from communications errors. 


Remote AS/400 System 


ICcF 


Program Database 


File File 
Display File 
ciwsoo 
Remote AS/400 System 
ICFOO 
Program 
Write Detach ICF Read | Program Database 
>_> 
ICFO1 >| 
File File 
ICFO2 
ICFOS 
ICF File 
Remote AS/400 System 
Local AS/400 System 
ICF Program Database 
File File 
Remote AS/400 System 
ICF Program Database 
File File 


Figure 10-19. Program Ends the Session 
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DDS Source: The DDS for the ICF file (CMNFIL) is illus- 
trated in Figure 10-20. 


3900 


4 
4 
4 
4 
4 
4 
4 
4 


4 


000 
100 
200 
300 
400 
500 
600 
700 
800 
900 


5000 
5100 
5200 
5300 
5400 
5500 
5600 
5700 


QICFPUB/ICFLIB 
CMNFIL 


[RK KAKKRKEKRE KEKE KEKE KER ER ERK EKER EK ERE RRR KEK ERE KERR EKER ER ER ERR EKER ERE 


A* 
A* 
A* 
A* 


ICF FILE 
USED IN SOURCE MULTIPLE SESSION PROGRAM 


* 
* 
* 
* 


[RK KKKKKEK EKER KKK ER EKER EKER KER EK ERE RR KK EK ERE KERR RR ER ER ER ERK ERR ERE 


A 


rPrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr,rp 


R 


wa 


wv 


Eo) 


Eo) 


ITMRSP 


RECITM 
ITEMNO 
DESC 
QTYLST 
QTYOH 
QTY00 
QTYBO 
UNITQ 
PRO1 
PROS 
UFRT 
SLSTM 
SLSTY 
CSTTM 
CSTTY 
PRO 
LOS 
FILL1 
DTLRSP 


RECCUS 
CUSTNO 
DNAME 

DLSTOR 
DSLSTM 
DSPMO1 
DSPMO2 
DSPM03 
DSTTYD 
IDEPT 

FILL2 

DETACH 


EOS 
EVKREQ 
PGMID 
LIB 
ITMREQ 


ITEMNO 
DTLREQ 


CUSTNO 


w 


Re 
DOTFWOFPMOOINNNMNNNN ODE 


Re 


o 


e w 
NwWrPowoVoononr 


on 


kK kK KK 


6 


INDARA 


RECID(1 'I') 


fas) 


eo 2 oe <2 


NMNNNNNN ND © PP 


RECID(1 'C') 
RCVTRNRND (90) 


oo 2 2 © oe © 


DETACH 


EOS 


EVOKE (&LIB/&PGMID) 


INVITE 


INVITE 
0 
END OF SOURCE 
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Figure 10-20. DDS for Source Program Multiple Session Inquiry Using CMNFIL 
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10/06/87 
10/06/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/07/87 
10/06/87 
10/06/87 
10/06/87 
10/13/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/13/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/12/87 
10/06/87 
10/06/87 
10/06/87 
10/06/87 
10/13/87 
10/06/87 
10/06/87 
10/13/87 
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The DDS for the display file (DSPFIL) is illustrated in 


Figure 10-21. 


000100871007 
000200871007 
000300871007 
000400871007 
000500871007 
000600871007 
000700871008 
000800871008 
000900871007 
001000871007 
001100871007 
001200871007 
001300871007 
001400871007 
001500871007 
001600871007 
001700871007 
001800871008 
001900871008 
002000871007 
002100871013 
002200871008 
002300871008 
002400871008 
002500871008 
002600871007 
002700871008 
002800871007 
002900871007 
003000871007 
003100871008 
003200871008 
003300871007 
003400871007 
003500871007 
003600871007 
003700871007 
003800871007 
003900871007 
004000890321 
004100871008 
004200871008 
004300871007 
004400871008 
004500871007 
004600871008 
004700871007 
004800871008 
004900871013 
005000871008 
005100871008 
005200871008 
005300871008 
005400871008 
005500871007 
005600871007 
005700871007 
005800871007 
005900871007 
006000871007 
006100871007 
006200871007 
006300871007 
006400871007 
006500871007 
006600871007 
006700871007 
006800871007 
006900871007 
007000871007 
007100871007 
007200871007 
007300871007 
007400871007 
007500871008 
007600871008 
007700871008 
007800871008 


Figure 10-21 (Part 1 of 2). DDS for Source Program Multiple 


[iti pasar SG SSSI SSSI I IDE SISG SIS ISN ISG IDI ISG 


Ax * 
Ax DISPLAY FILE * 
Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 
Ax * 


[SEB E HSS GSS SSSI SSSI SIS IIE SSCS SSIS III III II IIR 
Ax BEGINNING MENU 
[eee rai 
A DSPSIZ(*DS3) 
CFO1(99) CFO2(98) CFO3(97) 
R CIMENU TEXT('MENU FOR INQUIRY') 
34' INQUIRY MENU' 


1 
3 1'Select one of the following:' 
4 


A 

A 

A 

A 

A 3'1. Item inquiry' 

A 5 3'2. Customer inquiry! 
A 11 1'Option:' 

A OPTION IN 1 11 9VALUES('1' '2') 

A 19 5DFT('CMD KEY 1 - END ') 
A 
A 
A 
A 


R DTLMNU TEXT('CUSTOMER INQUIRY SCREEN 1') 


2  2DFT('ENTER CUSTOMER') 
CUSTNO 6N OI 2 20 
19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 


[tpiddaadarnbinnininscoiiinininininiok 


Ax CUSTOMER INQUIRY SCREEN 


[ieiddadcaniniinninisnisciioiiininininiiek 


A R DTLSCR TEXT('CUSTOMER INQUIRY SCR. #2') 
A 1 3DFT('CUST DPT LAST ORD 
A $MTH1 &MTH2 $MTH3 
A THIS YTD NAME') 

A CUSTN 6N 2 2 

A DEPT 3NQ0 2 9 

A DLSTR 6NO 2 13 

A DSLSM ONO 2 22 

A DSPM1 ONO 2 32 

A DSPM2 ONO 2 42 

A DSPM3 ONO 2 52 

A DSTYD 11IN0 2 62 

A CNAME 5 274 

A 19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 
Ax 

[EEE EE 

Ax ITEM INQUIRY SCREEN 

(Vrtrtttrc crc corer cree. 

A R ITMMNU TEXT('ITEM INQUIRY SCREEN ONE') 
A 2 2DFT('ENTER ITEM NUMBER') 
A ITEMNO 6N OI 2 20 

A 19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 
ttre ttrcr croc crcr errs. 

Ax ITEM DISPLAY 

\VIttrt ttl cccrcccrctec rey 

A R ITMSC2 TEXT('ITEM INQUIRY SCREEN TWO') 
A OVERLAY 

A 4 2DFT('DESC-') 

A DSC 30 4 8 

A 5 2DFT('QUANTITY AVAILABLE') 
A QAVAIL INO 5 25 

A 6 11DFT('ON HAND') 

A QTYH INO 6 25 

A 7 11DFT('ON ORDER') 

A Qryo INO 7 25 

A 8 11DFT('BACK ORDER') 

A QTYB INO 8 25 

A 9 2DFT('UNIT OF MEASURE') 
A UNT 2: 9 30 

A 10 2DFT('PRICE PER UNIT') 

A PRI 7Y 2 10 24EDTCDE(3) 

A 11 8DFT('QUANTITY') 

A PR5 7Y @ 11 25EDTCDE(3) 

A 12 8DFT('FREIGHT') 

A UFR 5Y 2 12 26EDTCDE(3) 

A 13 32DFT('MORE... ') 

A 19 5DFT('CMD KEY 1 - END ') 
A 19 23DFT(' 2 - MAIN MENU ') 
A 19 40DFT(' 3 - ITEM MENU ') 
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007900871008 NRK RRKAK KKK RI KK ER IRE RARE 


008000871008 Ax ITEM ADDITIONAL DISPLAY 


008100871008 \VItlirrtriccror ccc rcrcror ery 

008200871007 A R ITMSC3 TEXT('ITEM INQUIRY SCREEN 3 ') 
008300871007 A OVERLAY 

008400871007 A 5 2DFT('SALES MONTH') 
008500871007 A SLSM 9Y 2. 5 16EDTCDE(1) 
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008700871007 A SLSY 11Y 2. 6 14EDTCDE(1) 

008800871007 A 7 2DFT('COSTS MONTH') 
008900871007 A CSTM 9Y 2 7 16EDTCDE(1) 

009000871007 A 8 8DFT('Y-T-D') 

009100871007 A CSTY 11Y 2. 8 14EDTCDE(1) 

009200871007 A 9 2DFT('PROFIT PCT') 
009300871007 A PROFIT 5Y 2 9 22EDTCDE(1) 

009400871007 A 10 2DFT('LOST SALES') 

009500871007 A LOSTS 9Y 2 10 16EDTCDE(1) 

009600871008 A 19 5DFT('CMD KEY 1 - END ') 
009700871008 A 19 23DFT(' 2 - MAIN MENU ') 
009800871008 [XIII III Ie 

009900871007 Ax — TIMOUT SCREEN. 

010000871008 [III IIE 

010100871007 A R TIMOUT TEXT('TIME OUT SCREEN') 
010200871007 A OVERLAY 

010300871007 A 20 2DFT('REMOTE SYSTEM TIMED OUT. ENTER 
010400871007 1 TO TRY AGAIN OR 2 TO END.') 
010500871007 A TIMRSP 1 120 61 


Figure 10-21 (Part 2 of 2). DDS for Source Program Multiple 
Session Inquiry Using DSPFIL 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/CMNFIL) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(CMNFIL) ACQPGMDEV(*NONE) MAXPGMDEV (4) 
WAITRCD(30) TEXT("SOURCE ICF FILE FOR MULTIPLE 
SESSION PROGRAM") 


The commands needed to define the four program device 
entries are: 
OVRICFDEVE PGMDEV(ICFOQ) RMTLOCNAME (CHICAGO) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICFQ1) RMTLOCNAME (NEWYORK) FMTSLT(*RECID) 
OVRICFDEVE PGMDEV(ICFO2) RMTLOCNAME(DETROIT) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICFQ3) RMTLOCNAME (MADISON) FMTSLT(*RECID) 


Program Explanation: The following explains the structure 
of the program examples illustrated in Figure 10-22 on 
page 10-37 and Figure 10-23 on page 10-51. The ICF file 
used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference numbers 
in the explanation below correspond to the numbers in the 
following program examples. 


In the following examples, the ICF file used in the first 
example is externally described, whereas the ICF file used in 
the second example is a program-described file. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the way the user- 
defined formats and the system-supplied formats are used. 
All output operations to the ICF file in the first example are 
done using the WRITE statement with the record format 
name coded as an operand. The output operations to the 
ICF file in the second example using system-supplied 
formats are issued with the system-supplied format coded as 
literal operand. 


Differences between the first and second example are 
described in each of the following descriptions as necessary. 


This section defines the ICF file (CMNFIL) and the 
display file (DSPFIL) used in the program. 


CMNFIL is the ICF file used to send records to and 
receive records from each of the four target programs. 
CMNFIL is implemented with the file-level keyword, 
INDARA, indicating a separate indicator area is used. 


DSPFIL is the display file used to receive user’s 
requests and to report the information received based 
on the request. 


The control area clause in the select statements of 
CMNFIL and DSPFIL is used to define the I/O feed- 
back area. Information from the I/O feedback is used 
to determine the major/minor return code, record 
format, and command key pressed. 


Note: In the program using system-supplied formats, 
the input records for CMNFIL are explicitly coded in the 
program since CMNFIL is now treated as a program- 
described file. The system-supplied file, QICDMF, 
could have been used instead of CMNFIL. Using the 
system-supplied file can be done by specifying 
QICDMF in the file specification, or by using an 
OVRICFF command to change the name from CMNFIL 
to QICDMF. 


DSP-ERROR SECTION and CMN-ERROR SECTION 
define the error handling procedures for I/O errors on 
the DSPFIL and CMNFIL. A DSPFIL I/O error causes 
the program to end, and an error message to be sent 
to the printer file. The section for CMNFIL file I/O 
errors checks the major/minor return code to determine 
if the error is recoverable. If the error is recoverable 
(major code 83), it sets a flag (ERR-SW) to 1 and 
returns to the program. Furthermore, when 
major/minor code 3431 (input data truncated) is 
received, it is saved but not considered as an error, 
and takes an exit. 


The program opens the files to be used and initializes 
the ICF file separate indicator area. 


If the ERR-SW switch is set to 1, indicating that a 
recoverable error has occurred, the program deter- 
mines whether the open retry count limit nine has been 
exceeded. If it has, the program goes to and then 
ends. If the limit count is less than nine, one is added 
to the count and control passes to and then to j 
to try to open the file. 


The four program devices used by the program are 
explicitly acquired. 

The device for the work station is implicitly acquired 
when the DSPFIL file is opened. 


Also, the evoke requests are issued to the remote 
systems by passing control to [g. 


When control returns from [¥J, the main menu (record 
format CIMENU) is then written to the work station. 


A read operation is issued to the display device, and 
the program waits for an input request from the user. 
When a record is returned, the last record format used 
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(as specified in the RCD-FMT field in the I/O control 
area) is checked. Based on the value in RCD-FMT, 
the program branches to the appropriate routine. 


If a match is not found for the display record format, 
the main menu (CIMENU) is written to the work station 
and control is returned to J. 


This routine is called if the request is made from the 
main menu (CIMENU). If the CMD-KEY variable is set 
to '01', indicating that the operator pressed command 
key 1, the four transactions and sessions are ended 
and the program ends. If the operator entered option 
1, the program writes the Item Inquiry menu (ITMMNU) 
to the work station and returns to J. 


If the option is not 1, the Customer Inquiry menu 
(DTLMNU) is written to the work station and control is 
passed to J. 


The rest of this chapter discusses the details of the 
control is passed to jj. 


This routine is called when the user is requesting an 
item inquiry (record format ITMMNU). If command key 
1 (CMD-KEY = '01') is pressed, control passes to FX], 
and then to J, the four transactions end, and the 
program ends. If command key 2 is pressed, the 
inquiry request is canceled, the main menu (CMENU) 
is written to the work station, and the program returns 


io Eg. 


The item number read from the work station is checked 
for value range. If the range is from 0 to 399999, then 
the request is sent to the target program on program 
device ICFO1. 


If the range is from 400000 to 699999, the request is 
sent to the target program on program device ICF02. 


If the range is from 700000 to 899999, the request is 
sent to the target program on program device ICF03. 


The request is sent to the appropriate target program 
by writing data to the program device using format 
ITMREQ. The INVITE keyword is specified as part of 
the ITMREQ format to give the target program permis- 
sion to send. 


A read request is issued to the program device to 
receive the response to the inquiry. 


The read is an implied read-from-invited-program- 
devices because no record format is specified in the 
read statement. 


Control goes to [J to process the item information 
based on the input data received and the result written 
to the screen using format ITMSC2. 


After returning from [gf], the program returns to J. 


Note: In the program using system-supplied formats, 
the $$SEND format is used as a literal instead of the 
user-defined ITMREQ record format name. 


This routine is called when the target program 
responds to a request for an item record. If the 
returned item number is 0 or less, the request is not 
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valid and a new Item Inquiry menu (ITMMNU) is written 
to the work station. 


The program then performs the calculations to set the 
quantity fields and writes the result to the requesting 
work station using record format ITMSC2. 


The program then returns to the calling routine. 


This routine is called to process the next user request. 
If command key 1 (CMD-KEY = '01') is pressed, the 
transactions and session are ended [RJ, and control 
goes to AJ to end the program. 


If command key 2 is pressed, the main menu 
(CMENV) is written to the work station. If command 
key 3 is pressed, the Item Inquiry menu is written to 
the work station, and the program returns to J. By 
pressing Enter, the profit and loss figures are calcu- 
lated and written to the work station before returning 
control to fj. 


This routine calculates the profit and loss figures for 
the second screen of the requested item number. 


This routine is called when a request is read from the 
Customer Inquiry menu (DTLMNU). If command key 1 
(CMD-KEY = '01') is pressed, the transactions and ses- 
sions are ended. If command key 2 (CMD-KEY = '02') 
is pressed, the main menu (CIMENU) is written to the 
work station and the program returns to [j. 


The customer inquiry request is sent to the target 
program by writing data to the program device ICF0O 
using format DTLREQ. The INVITE keyword is speci- 
fied as part of the DLTREQ format to give the target 
program permission to send. 


Control goes to to retrieve the customer detail 
information. 


Routine [&J is called to continue the customer infor- 
mation processing. 


The program returns to [j. 


Note: In the program using system-supplied formats, 
the write operation is issued with the $$SEND format 
specified as literal, in the user-supplied format, WRITE 
was issued with a record format name DTLREQ. 


The information supplied by the target program in 
response to a request for a customer detail is pro- 
cessed in this routine. If the customer number is 0 or 
less, the request is not valid and the main menu 
(record format CIMENU) is written to the work station. 
The program then returns to J. 


Control goes to [ER] to retrieve the customer detail 
information, and the result is written to the work station 
using record format DTLSCR. 


The program then returns to J. 


This routine is called from [fJ, and handles the user's 
request following the display of the customer informa- 
tion. Command key 1 ends the job, command key 2 

displays the main menu (CMENU), and pressing Enter 
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displays the Customer Inquiry menu (DTLMNU). Then, 
control returns to J. 


This routine issues the read operation to the program 
device. 


This read is an implied read-from-invited-program- 
devices because no record format is specified on the 
read statement. 


A check is made of the MAJ-MIN return code for pos- 
sible error conditions on a successful return (control is 
automatically passed to —4 for non-successful I/O 
operations). A 0310 major-minor return code means 
the remote system has timed out. (The wait time was 
specified on the CRTICFF command.) If no data was 
received (MAJ-MIN - 03xx), the request is sent again to 
the remote system. Finally, if the data returns in the 
wrong format, Control is passed to Rg. 


The customer information received from the target 
program is processed, and the result is written to the 
user work station using screen format DTLBLK. 


Control returns to the calling routine. 


Note: The program using system-supplied formats 
issues the READ statement with the file name CMNFIL 
specified in the operand without a record format name. 


This routine builds the evoke requests to send to the 
remote systems. Because the DDS keyword for the 
record format only specifies the field identifiers with the 
record, this code moves the literal value CTDMULCL to 
the field PGMID, and ICFLIB to the field LIB. 


When the program start request is received at the 
remote system, ICFLIB is searched for CTDMULCL 
and that program then starts. CTDMULCL is a CL 
program that contains the following statements: 


ADDLIBLE ICFLIB 
CALL ICFLIB/CTDMUL 


Note: In the program using system-supplied formats, 
the evoke request is issued using the WRITE state- 
ment followed with a $$EVOKNI format coded as literal 
in the operand. 


The library and program (ICFLIB/CTFMULCL) are 
specified as part of the $$EVOKNI format. CTFMULCL 
is a CL program that contains the following statements: 


ADDLIBLE ICFLIB 
CALL ICFLIB/CTFMUL 


This routine ends the transactions and closes the files. 
The ERR-SW indicator is set again, and control returns 
to the calling routine. 


This routine is run when the program detects data in 
an incorrect record format. It writes an error message 
to the printer file, ends the program, and implicitly ends 
the session. 


This routine issues the detach function to the ICF file 
for each of the four program devices. In the program 
using the system-supplied format, the write operation is 
issued using $$SENDET format, but in the program 


using the user-supplied format, it is the record format 


name DETACH. 


EQ] This routine releases the program devices and close 
the files. The program ends. 


PROGVAMY to) be ed 8 eine, Sy Sey ee Bee CSDMUL 
Libary” vee cee ee, Ga ad oe ee wee ee a 8 ICFLIB 
SOUPCES TH G2 83 eo a. oe Sao ae ea QICFPUB 
LTDRANY ce Gee) eee He ea EE ICFLIB 
Source member .........24-3 CSDMUL 10/03/90 14:28:28 
Generation severity level .....: 29 
Text ‘description’. ........: CBL Multiple Session Inquiry - Source DDS 
Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........ : + *NOMAX 
Message limit severity ......: 29 
Print file. ........ 2... . 2: + QSYSPRT 
LADPANY 6. 668 ape ge bye le eS *LIBL 
ELPS! TV AQGING! 6) 63 a, ee 8) ae a eS *NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ........... : + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........3: *YES 
Target release. . 2... . 2... ~:~ *CURRENT 
User profile. ........... :  *USER 
Authority” is 66 ay a ew ee a *LIBCRTAUT 
Compiler. ......... 4.4. 1 IBM AS/400 COBOL/400 
1 000100 IDENTIFICATION DIVISION. 09/30/87 
2 000200 PROGRAM-ID. CSDMUL. 09/30/87 
OQOO3 OO kx KAA KK KAKA KK KKK KEK ERK R RRR RRR RRR ER RRR RRR RRR ERE RRR ERE RRR ERERERRE 09/30/87 
000400* THIS PROGRAM ASSIGNS FOUR SESSIONS AS FOLLOWS: * 09/30/87 
000500* "ICFQO' TO INQUIRE ABOUT A CUSTOMER ACCOUNT BEFORE AN * 09/30/87 
000600* ORDER IS PROCESSED. * 09/30/87 
000700* "ICFQ1' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 09/30/87 
000800* BEING ORDERED (ITEM @00001 THRU 399999). * 09/30/87 
000900* "ICFQ2' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 09/30/87 
001000* BEING ORDERED (ITEM 400000 THRU 699999). * 09/30/87 
001100* "ICFQ3' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 09/30/87 
001200* BEING ORDERED (ITEM 700000 THRU 999999). * 09/30/87 
001300* A DISPLAY DEVICE IS USED TO ENTER THE REQUEST ( USING A * 09/30/87 
001400* CUSTOMER AND AN ITEM MENU) THAT IS SENT TO THE REMOTE * 09/30/87 
001500* SYSTEM. * 10/15/87 
OO LO OD kee KAA KR ARK KARR RAK KEKE RRR ERE E RRR ERE ER ERE RE KR RRR ERR ERE ERE ERERR RE 09/30/87 
3 001700 ENVIRONMENT DIVISION. 09/30/87 
4 001800 CONFIGURATION SECTION. 09/30/87 
5 01900 SOURCE-COMPUTER. IBM-AS400. 01/15/88 
6 002000 OBJECT-COMPUTER. IBM-AS400. 01/15/88 
7 002100 SPECIAL-NAMES. I-0-FEEDBACK IS IO0-FEEDBACK 09/30/87 
8 002200 OPEN-FEEDBACK IS OPEN-FBA. 09/30/87 
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9 002300 INPUT-OUTPUT SECTION. 09/30/87 


10 002400 FILE-CONTROL. 09/30/87 
002500* 09/30/87 
OOZ2 600 kx KAA K KAA KKA RK RK EKER ERK ERE E RRR RRR KER ERE REK RRR RR RRR REE EREERRR 09/30/87 
002700* * 09/30/87 
002800* FILE SPECIFICATIONS * 09/30/87 
002900* * 09/30/87 
003000* CMNFIL : ICF FILE USED TO SEND A REQUEST TO ONE * 10/03/90 
003100* OF FOUR DIFFERENT TARGET PROGRAMS. MULTIPLE * 09/30/87 
003200* SESSIONS ARE ACTIVE CONCURRENTLY. * 09/30/87 
003300* * 09/30/87 
003400* DSPFIL : DISPLAY FILE USED TO ENTER A REQUEST TO BE * 09/30/87 
003500* SENT TO A REMOTE SYSTEM. * 09/30/87 
003600* * 09/30/87 
C037 OD KAR KAA KAKA K KKK KKK RRR RRR RRR ER ERR RRR ERE E RRR EKER ERE RRR EKER EKER EERE 09/30/87 

11 003800 SELECT CMNFIL ASSIGN TO WORKSTATION-CMNFIL-SI 10/13/87 

12 003900 ORGANIZATION IS TRANSACTION 09/30/87 

13 004000 CONTROL-AREA IS TR-CTL-AREA 09/30/87 

14 004100 FILE STATUS IS STATUS-IND MAJ-MIN. 09/30/87 

15 004200 SELECT DSPFIL ASSIGN TO WORKSTATION-DSPFIL 09/30/87 

16 004300 ORGANIZATION IS TRANSACTION 09/30/87 

17 004400 CONTROL-AREA IS DISPLAY-FEEDBACK 09/30/87 

18 004500 FILE STATUS IS STATUS-DSP. 09/30/87 

19 004600 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 09/30/87 

20 004700 DATA DIVISION. 09/30/87 

21 004800 FILE SECTION. 09/30/87 

22 004900 FD CMNFIL 09/30/87 

23 005000 LABEL RECORDS ARE STANDARD. 09/30/87 

24 005100 01 CMNREC. 09/30/87 

25 005200 COPY DDS-ALL-FORMATS-I-0 OF CMNFIL. 02/28/89 

26 +000001 05 CMNFIL-RECORD PIC X(196). <-ALL-FMTS 
+000002* I-0 FORMAT: ITMRSP FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000003* <-ALL-FMTS 

27 +000004 05 ITMRSP REDEFINES CMNFIL-RECORD. <-ALL-FMTS 

28 +000005 06 RECITM PIC X(1). <-ALL-FMTS 

29 +000006 06 ITEMNO PIC S9(6). <-ALL-FMTS 

30 +000007 06 DESC PIC X(30). <-ALL-FMTS 

31 +000008 06 QTYLST PIC S9(7). <-ALL-FMTS 

32 +000009 06 QTYOH PIC S9(7). <-ALL-FMTS 

33 +000010 06 QTYOO PIC S9(7). <-ALL-FMTS 

34 +000011 06 QTYBO PIC S9(7). <-ALL-FMTS 

35 +000012 06 UNITQ PIC X(2). <-ALL-FMTS 

36 +000013 06 PROQ1 PIC $9(5)V9(2). <-ALL-FMTS 

37 +000014 06 PRO5 PIC S9(7). <-ALL-FMTS 

38 +000015 06 UFRT PIC $9(3)V9(2). <-ALL-FMTS 

39 +000016 06 SLSTM PIC $9(7)V9(2). <-ALL-FMTS 

40 +000017 06 SLSTY PIC $9(9)V9(2). <-ALL-FMTS 

41 +000018 06 CSTTM PIC $9(7)V9(2). <-ALL-FMTS 

42 +000019 06 CSTTY PIC $9(9)V9(2). <-ALL-FMTS 

43 +000020 06 PRO PIC $9(3)V9(2). <-ALL-FMTS 

44 +000021 06 LOS PIC $9(7)V9(2). <-ALL-FMTS 

45 +000022 06 FILL1 PIC X(56). <-ALL-FMTS 
+000023* INPUT FORMAT:DTLRSP FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000024* <-ALL-FMTS 

46 +000025 05 DTLRSP-I REDEFINES CMNFIL-RECORD. <-ALL-FMTS 

47 +000026 06 RECCUS PIC X(1). <-ALL-FMTS 

48 +000027 06 CUSTNO PIC S9(6). <-ALL-FMTS 

49 +000028 06 DNAME PIC X(30). <-ALL-FMTS 

50 +000029 06 DLSTOR PIC S9(6). <-ALL-FMTS 

51 +000030 06 DSLSTM PIC S9(9). <-ALL-FMTS 

52 +000031 06 DSPMO1 PIC S9(9). <-ALL-FMTS 

53 +000032 06 DSPMO2 PIC S9(9). <-ALL-FMTS 

54 +000033 06 DSPMO03 PIC S9(9). <-ALL-FMTS 

55 +000034 06 DSTTYD PIC S9(11). <-ALL-FMTS 

56 +000035 06 IDEPT PIC $9(3). <-ALL-FMTS 

57 +000036 06 FILL2 PIC X(57). <-ALL-FMTS 
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+000037* OUTPUT FORMAT:DTLRSP FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000038* <-ALL-FMTS 
+000039 05 DTLRSP-O REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000040 06 RECCUS PIC X(1). <-ALL-FMTS 
+000041 06 CUSTNO PIC S9(6). <-ALL-FMTS 
+000042 06 DNAME PIC X(30). <-ALL-FMTS 
+000043 06 DLSTOR PIC S9(6). <-ALL-FMTS 
+000044 06 DSLSTM PIC S9(9). <-ALL-FMTS 
+000045 06 DSPMO1 PIC S9(9). <-ALL-FMTS 
+000046 06 DSPMO2 PIC S$9(9). <-ALL-FMTS 
+000047 06 DSPM03 PIC S9(9). <-ALL-FMTS 
+000048 06 DSTTYD PIC $9(11). <-ALL-FMTS 
+000049 06 IDEPT PIC $9(3). <-ALL-FMTS 
+000050 06 FILL2 PIC X(57). <-ALL-FMTS 
+000051* I-0 FORMAT:DETACH FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000052* <-ALL-FMTS 
+000053* 05 DETACH REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000054* I-0 FORMAT: E0S FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000055* <-ALL-FMTS 
+000056* 05 EOS REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000057* INPUT FORMAT: EVKREQ FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000058* <-ALL-FMTS 
+000059* 05 EVKREQ-I REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000060* OUTPUT FORMAT: EVKREQ FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000061* <-ALL-FMTS 
+000062 05 EVKREQ-0 REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000063 06 PGMID PIC X(10). <-ALL-FMTS 
+000064 06 LIB PIC X(10). <-ALL-FMTS 
+000065* 1-0 FORMAT: ITMREQ FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000066* <-ALL-FMTS 
+000067 05 ITMREQ REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000068 06 ITEMNO PIC S9(6). <-ALL-FMTS 
+000069* 1-0 FORMAT:DTLREQ FROM FILE CMNFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000070* <-ALL-FMTS 
+000071 05 DTLREQ REDEFINES CMNFIL-RECORD. <-ALL-FMTS 
+000072 06 CUSTNO PIC S9(6). <-ALL-FMTS 
005300 FD DSPFIL 09/30/87 
005400 LABEL RECORDS ARE STANDARD. 09/30/87 
005500 01 DSPREC. 09/30/87 
005600 COPY DDS-ALL-FORMATS-I-0 OF DSPFIL. 02/27/89 
+000001 @5 DSPFIL-RECORD PIC X(79). <-ALL-FMTS 
+000002* INPUT FORMAT: CIMENU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000003* MENU FOR INQUIRY <-ALL-FMTS 
+000004 05 CIMENU-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
+000005 06 CIMENU-I-INDIC. <-ALL-FMTS 
+000006 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 
+000007 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 
+000008 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 
+000009 06 OPTION PIC X(1). <-ALL-FMTS 
+000010* OUTPUT FORMAT: CIMENU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000011* MENU FOR INQUIRY <-ALL-FMTS 
+000012* 05 CIMENU-O REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
+000013* INPUT FORMAT:DTLMNU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000014* CUSTOMER INQUIRY SCREEN 1 <-ALL-FMTS 
+000015 05 DTLMNU-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
+000016 06 DTLMNU-I-INDIC. <-ALL-FMTS 
+000017 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 
+000018 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 
+000019 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 
+000020 06 CUSTNO PIC S9(6). <-ALL-FMTS 
+000021* OUTPUT FORMAT: DTLMNU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000022* CUSTOMER INQUIRY SCREEN 1 <-ALL-FMTS 
+000023* 05 DTLMNU-O REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
+000024* INPUT FORMAT:DTLSCR FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000025* CUSTOMER INQUIRY SCR. #2 <-ALL-FMTS 
+000026 05 DTLSCR-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
+000027 06 DTLSCR-I-INDIC. <-ALL-FMTS 
+000028 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 
+000029 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 
+000030 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 
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+000031* OUTPUT FORMAT:DTLSCR FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000032* CUSTOMER INQUIRY SCR. #2 <-ALL-FMT. 
99 +000033 05 DTLSCR-0 REDEFINES DSPFIL-RECORD. <-ALL-FMT. 
100 +000034 06 CUSTN PIC X(6). <-ALL-FMT. 
101 +000035 06 DEPT PIC $9(3). <-ALL-FMT. 
102 +000036 06 DLSTR PIC S9(6). <-ALL-FMT. 
103 +000037 06 DSLSM PIC S9(9). <-ALL-FMT. 
104 +000038 06 DSPM1 PIC S9(9). <-ALL-FMT. 
105 +000039 06 DSPM2 PIC S9(9). <-ALL-FMT. 
106 +000040 06 DSPM3 PIC S$9(9). <-ALL-FMT. 
107 +000041 06 DSTYD PIC $9(11). <-ALL-FMT. 
108 +000042 06 CNAME PIC X(5). <-ALL-FMT 

+000043* INPUT FORMAT: ITMMNU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000044* ITEM INQUIRY SCREEN ONE <-ALL-FMT. 
109 +000045 05 ITMMNU-I REDEFINES DSPFIL-RECORD. <-ALL-FMT. 
110 +000046 06 ITMMNU-I-INDIC. <-ALL-FMT. 
111 +000047 07 IN99 PIC 1 INDIC 99. <-ALL-FMT. 
112 +000048 07 IN98 PIC 1 INDIC 98. <-ALL-FMT. 
113 +000049 07 IN97 PIC 1 INDIC 97. <-ALL-FMT. 
114 +000050 06 ITEMNO PIC S9(6). <-ALL-FMT. 

+000051* OUTPUT FORMAT: ITMMNU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000052* ITEM INQUIRY SCREEN ONE <-ALL-FMT. 

+000053* 05 ITMMNU-O REDEFINES DSPFIL-RECORD. <-ALL-FMT. 

+000054* INPUT FORMAT: ITMSC2 FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT 

+000055* ITEM INQUIRY SCREEN TWO <-ALL-FMT. 
115 +000056 05 ITMSC2-I REDEFINES DSPFIL-RECORD. <-ALL-FMT. 
116 +000057 06 ITMSC2-I-INDIC. <-ALL-FMT. 
117 +000058 07 IN99 PIC 1 INDIC 99. <-ALL-FMT. 
118 +000059 07 IN98 PIC 1 INDIC 98. <-ALL-FMT. 
119 +000060 07 IN97 PIC 1 INDIC 97. <-ALL-FMT. 

+000061* OUTPUT FORMAT: ITMSC2 FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000062* ITEM INQUIRY SCREEN TWO <-ALL-FMT. 
120 +000063 05 ITMSC2-0 REDEFINES DSPFIL-RECORD. <-ALL-FMT. 
121 +000064 06 DSC PIC X(30). <-ALL-FMT. 
122 +000065 06 QAVAIL PIC S9(7). <-ALL-FMT. 
123 +000066 06 QTYH PIC S9(7). <-ALL-FMT. 
124 +000067 06 QTYO PIC S9(7). <-ALL-FMT. 
125 +000068 06 QTYB PIC S9(7). <-ALL-FMT 
126 +000069 06 UNT PIC X(2). <-ALL-FMT. 
127 +000070 06 PR1 PIC $9(5)V9(2). <-ALL-FMT. 
128 +000071 06 PR5 PIC S9(7). <-ALL-FMT. 
129 +000072 06 UFR PIC $9(3)V9(2). <-ALL-FMT. 

+000073* INPUT FORMAT: ITMSC3 FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000074* ITEM INQUIRY SCREEN 3 <-ALL-FMT. 
130 +000075 05 ITMSC3-I REDEFINES DSPFIL-RECORD. <-ALL-FMT. 
131 +000076 06 ITMSC3-I-INDIC. <-ALL-FMT. 
132 +000077 07 IN99 PIC 1 INDIC 99. <-ALL-FMT. 
133 +000078 07 IN98 PIC 1 INDIC 98. <-ALL-FMT. 
134 +000079 07 IN97 PIC 1 INDIC 97. <-ALL-FMT. 

+000080* OUTPUT FORMAT: ITMSC3 FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMT. 

+000081* ITEM INQUIRY SCREEN 3 <-ALL-FMT. 
135 +000082 05 ITMSC3-0 REDEFINES DSPFIL-RECORD. <-ALL-FMT 
136 +000083 06 SLSM PIC $9(7)V9(2). <-ALL-FMT 
137 +000084 06 SLSY PIC $9(9)V9(2). <-ALL-FMT. 
138 +000085 06 CSTM PIC $9(7)V9(2). <-ALL-FMT. 
139 +000086 06 CSTY PIC $9(9)V9(2). <-ALL-FMT. 
140 +000087 06 PROFIT PIC $9(3)V9(2). <-ALL-FMT 
141 +000088 06 LOSTS PIC $9(7)V9(2). <-ALL-FMT. 
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+000089* INPUT FORMAT: TIMOUT FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 

+000090* TIME OUT SCREEN <-ALL-FMTS 

+000091 05 TIMOUT-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 

+000092 06 TIMOUT-I-INDIC. <-ALL-FMTS 

+000093 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 

+000094 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 

+000095 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 

+000096 06 TIMRSP PIC X(1). <-ALL-FMTS 

+000097* OUTPUT FORMAT: TIMOUT FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 

+000098* TIME OUT SCREEN <-ALL-FMTS 

+000099* 05 TIMOUT-0O REDEFINES DSPFIL-RECORD. <-ALL-FMTS 

005700 FD QPRINT 09/30/87 
005800 LABEL RECORDS ARE OMITTED. 09/30/87 
005900 01 PRINTREC. 01/14/88 
006000 05 RC PIC 9999. 01/15/88 
006100 05 ERRMSG PIC X(128). 01/14/88 
006200 WORKING-STORAGE SECTION. 09/30/87 
006300 77 STATUS-IND PIC X(2). 09/30/87 
006400 77 STATUS-DSP PIC X(2). 09/30/87 
006500 77 MAJ-MIN-SAV PIC X(4). 09/30/87 
006600 77 EOF-PFILE-SW PIC X VALUE "0". 09/30/87 
006700 77 ERR-SW PIC X VALUE "0". 09/30/87 
006800 77 INDON PIC 1 VALUE B"1". 09/30/87 
006900 77 INDOFF PIC 1 VALUE B"0". 09/30/87 
007000 77 OPEN-COUNT PIC 9(1) VALUE 0. 09/30/87 
007100 77 LEN PIC 9(10)V9(5) COMP. 09/30/87 
007200 77 PROFM PIC 9(7)V9(2) COMP-4. 09/30/87 
007300 77 CMD2 PIC X(31) 09/30/87 
007400 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 09/30/87 
007500 01 SUBKEY-VALUE. 09/30/87 
007600 05 SUBKEY PIC 9(3) VALUE 0. 09/30/87 
007700 01 TR-CTL-AREA. 09/30/87 
007800 05 FILLER PIC X(2). 09/30/87 
007900 05 PGM-DEV-NME PIC X(10). 09/30/87 
008000 05 RCD-FMT-NME PIC X(10). 09/30/87 
008100 01 CMNF-INDIC-AREA. 09/30/87 
008200 05 IN9O PIC 1 INDIC 90. 09/30/87 
008300 88 IN90-ON VALUE B"1". 09/30/87 
008400 88 IN90-OFF VALUE B"0". 09/30/87 
008500 01 DSPF-INDIC-AREA. 09/30/87 
008600 05 IN23 PIC 1 INDIC 23. 09/30/87 
008700 88 IN23-0N VALUE B"1". 09/30/87 
008800 88 IN23-OFF VALUE B"0". 09/30/87 
008900 05 IN97 PIC 1 INDIC 97. 09/30/87 
009000 88 IN97-ON VALUE B"1". 09/30/87 
009100 88 IN97-OFF VALUE B"0". 09/30/87 
009200 05 IN98 PIC 1 INDIC 98. 09/30/87 
009300 88 IN98-ON VALUE B"1". 09/30/87 
009400 88 IN98-OFF VALUE B"0". 09/30/87 
009500 05 IN99 PIC 1 INDIC 99. 09/30/87 
009600 88 IN99-ON VALUE B"1". 09/30/87 
009700 88 IN99-OFF VALUE B"0". 09/30/87 
009800 01 MAJ-MIN. 09/30/87 
009900 05 MAJ PIC X(2). 09/30/87 
010000 05 MI PIC X(2). 09/30/87 
010100 01 DISPLAY-FEEDBACK. 09/30/87 
010200 05 CMD-KEY PIC X(2). 09/30/87 
010300 05 FILLER PIC X(10). 09/30/87 
010400 05 RCD-FMT PIC X(10). 09/30/87 
010500/ 09/30/87 
010600 PROCEDURE DIVISION. 09/30/87 
010700 DECLARATIVES. 09/30/87 
010800* 10/14/87 
OLOQOD Kx KAA KK ARK KARR RRR KEK RRR KER EKER EKER KKK RR ER EK RRR ERE RE RE ERERERERR RE 02/21/89 
011000* * 02/21/89 
011100* AN ERROR ON THE DISPLAY FILE - DSPFIL - MAKES IT INACTIVE * 02/21/89 
011200* THE JOB IS ENDED. * 02/21/89 
011300* * 02/21/89 
OL LA OD kx x eA A KKK AK K ARK RARER RK RRR ERE RE RREK RRR KERR RRR ERRRRKERERERERERRERREREERRE 02/21/89 
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011500 DSP-ERROR SECTION. 

011600 USE AFTER STANDARD ERROR PROCEDURE ON DSPFIL. 
011700* 

011800 DSPFIL-EXCEPTION. 

011900 MOVE "DISPLAY ERROR. JOB TERMINATED" TO ERRMSG. 
012000 WRITE PRINTREC. 


012100 CLOSE CMNFIL DSPFIL QPRINT. 

012200 STOP RUN. 

012300* 

0112.40 02 a III IO IO RICCI IC ICI ICI RICCI I IIR RICE ICI IR AR AR 
012500* * 
012600* THIS SECTION HANDLES ERRORS ON THE CMNFIL. A PERMANENT * 
012700* SESSION ERROR WILL END THE JOB. * 
012800* * 


OL 29 OD kx KAA KK ARK KARR RK ERR RRR ERE RRR ER RR EKRE RRR ER EKER ER ER ER ER ER ERE ER ERRRE 
013000 CMN-ERROR SECTION. 

013100 USE AFTER STANDARD ERROR PROCEDURE ON CMNFIL. 

013200 CMNFIL-EXCEPTION. 

O13 300k xR KKK KARA KKK KEK RK RRR ERE E RRR ERE KERR RE REK RR REKERER ERE ERE RE REERRR 
013400* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION * 
013500* MAJOR CODE 34 - INPUT EXCEPTION. * 


O13 6 OOD kK AA KKK AK KARR KEKE KEK RRR ERE E RRR RRR ERR RERRERERRRE 


013700 IF MAJ-MIN = "3431" 

013800* DATA TRUNCATED IN INPUT AREA. SAVE RETURN CODE. 
013900 MOVE MAJ-MIN TO MAJ-MIN-SAV 

014000 GO TO EXIT-DECLARATIVES. 


014100* RECOVERABLE SESSION ERROR. CLOSE ICF FILE. 


014200 IF MAJ = "83" 

014300 MOVE MAJ-MIN TO RC 

014400 MOVE "PROGRAM STARTED AGAIN DUE TO SESSION ERROR" 

014500 TO ERRMSG 

014600 WRITE PRINTREC 

014700 MOVE "1" TO ERR-SW 

014800 GO TO EXIT-DECLARATIVES. 

014900* 

0150002 a EI IOI IO IOI ICI I I ICI ICI I ICI RIOR RI ICR ICI IR AIR A 
015100* WHEN THERE IS A PERMANENT SESSION ERROR DETECTED, * 
015200* THE MAJOR-MINOR CODE IS PLACED INTO A DATABASE * 
015300* FILE AND THE FILE IS PRINTED IN HEX USING COPYFILE. * 
0154002 a I IOI IO IOI ICI I IC IC ICR ICI ICI A IIR ICI IR AIR A 
015500* 


015600 GETFBA. 

015700 MOVE MAJ-MIN TO RC. 

015800 MOVE "PROGRAM TERMINATED DUE TO ERROR IN CMNFIL FILE" 
015900 TO ERRMSG. 

016000 WRITE PRINTREC. 

016100 CLOSE CMNFIL DSPFIL QPRINT. 

016200 STOP RUN. 

016300* 

016400 EXIT-DECLARATIVES. 

016500 EXIT. 


016600* 
016700 END DECLARATIVES. 

016800/ 

016900 START-PROGRAM SECTION. 

017000* 

017100 START-PROGRAM-PARAGRAPH. 
017200 Ey 

017300 OPEN I-0 CMNFIL DSPFIL 
017400 QUTPUT QPRINT. 

017500 MOVE ZEROS TO CMNF-INDIC-AREA. 
017600* 
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02/21/89 
02/21/89 
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09/30/87 
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02/21/89 
02/21/89 
02/21/89 
02/21/89 
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09/30/87 
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09/30/87 
09/30/87 
09/30/87 
09/30/87 
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O17 JOD KKK ARK KK AK KK ERR KERR KR RRR ERE ER EKER EKER RR ER ERR RRR RRR ER ER ERR ER ERRR 


017800* THE FOLLOWING TEST IS TO ATTEMPT RECOVERY IF AN ERROR * 
017900* OCCURS WHEN OPENING THE ICF FILE. * 
OLB OOD * xR KKK KAA KKA AKER EKER RRR R EKER ER RRR RRR ERE RER RR KRRERRRRREKERREKEREREERRE 
018100+ EJ 

018200 IF ERR-SW = "1" 

018300 THEN IF OPEN-COUNT IS = 9 

018400 THEN PERFORM DETACH-ROUTINE THRU DETACH-EXIT 

018500 GO TO END-JOB 

018600 ELSE 

018700 ADD 1 TO OPEN-COUNT 

018800 PERFORM ERROR-RECOVERY 

018900 GO TO START-PROGRAM-PARAGRAPH 

019000 ELSE 

019100 MOVE @ TO OPEN-COUNT. 

019200* 


O19 30D kx K ARK KAA K KEKE RRR RRR KER RRR RRR ERK KER RR ERER RRR KER ERE KER RRR ER EER RE 
019400* 

019500* THE DISPLAY DEVICE IS IMPLICITLY ACQUIRED WHEN THE 
019600* FILE IS OPENED. 

019700* 

019800* ALL OF THE ICF PROGRAM DEVICES ARE EXPLICITLY ACQUIRED. 
019900* 

020000* EACH OF THE FOUR TARGET PROGRAMS ARE EVOKED TO ESTABLISH 
020100* |= TRANSACTIONS WITH THE REMOTE SYSTEMS. 

020200* 

020300* THE MAIN INQUIRY MENU (CIMENU) IS WRITTEN TO THE USER'S 
020400* DISPLAY. 

020500* 

020600* EVOKE PROGRAM "CTDMUL" ON REMOTE SYSTEM IN LIBRARY ICFLIB. 
O20 7 OQ ee RAK K KK KEK KKK KKK KKK KKK KER EKER KKK KK KEKE ERR EERE KERR KK KEE RE REE ERER ER EK 
020800 Ej 

020900 ACQUIRE "ICFOO " FOR CMNFIL. 

021000 ACQUIRE "ICFO1 " FOR CMNFIL. 

021100 ACQUIRE "ICFQ2 " FOR CMNFIL. 

021200 ACQUIRE "ICFQ3  " FOR CMNFIL. 

021300 PERFORM EVOKE-ROUTINE THRU EVOKE-EXIT. 


* + FF FF FF HF HF HF F F 


021400* 

021500 WRITE DSPREC FORMAT IS "CIMENU" 
021600 INDICATORS ARE DSPF-INDIC-AREA. 
021700* 


(CVARSCCh ete te ee re ee 
021900* 
022000* DETERMINE USER'S REQUEST 

022100* 

022200* A READ TO THE DISPLAY DEVICE IS ISSUED TO RECEIVE 

022300* THE USER'S REQUEST. THE TYPE OF REQUEST MADE IS BASED ON THE 
022400* DISPLAY FORMAT CURRENTLY ON THE SCREEN. THE RECORD FORMAT 
022500* NAME IS EXTRACTED FROM THE I/O FEEDBACK AREA FOR THE DISPLAY 
022600* FILE AND USED TO DETERMINE WHAT ACTION SHOULD BE TAKEN NEXT. 
022700* 


O22 800K xR KAA K KK AKA KK KEKE KEK RRR KER EKER EKER KR ER RR ER EK RRR KERR RRR REE RERR RE 


022900* f¥ 


+ + FF FF F F 
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023000 READRQ. 


023100 READ DSPFIL INDICATORS ARE DSPF-INDIC-AREA. 
023200 IF RCD-FMT = "CIMENU" 

023300 PERFORM MENU-ROUTINE THRU MENU-EXIT 
023400 GO TO READRQ. 

023500 IF RCD-FMT = "ITMMNU" 

023600 PERFORM ITMIN-ROUTINE THRU ITMIN-EXIT 
023700 GO TO READRQ. 

023800 IF RCD-FMT = "ITMSC2" 

023900 PERFORM ITMRTN-ROUTINE THRU ITMRTN-EXIT 
024000 GO TO READRQ. 

024100 IF RCD-FMT = "ITMSC3" 

024200 PERFORM ITMRTN-ROUTINE THRU ITMRTN-EXIT 
024300 GO TO READRQ. 

024400 IF RCD-FMT = "DTLMNU" 

024500 PERFORM DTLIN-ROUTINE THRU DTLIN-EXIT 
024600 GO TO READRQ. 

024700 IF RCD-FMT = "DTLSCR" 

024800 PERFORM DTLRTN-ROUTINE THRU DTLRTN-EXIT 
024900 GO TO READRQ. 


025000 WRITE DSPREC FORMAT IS "CIMENU". 


025100 
025200 GO TO READRQ. 
025300/ 


O25 AOD KAR KAA KKK AK KK KK KEKE RRR RRR ERE EREK RRR KER ERE RRR RRR ERR ERE EREREREERER 


025500* 
025600* 
025700* 


MAIN MENU 


025800* THE MAIN MENU IS READ TO DETERMINE THE REQUEST ENTERED 
025900* BY THE USER. IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM 
026000* IS ENDED. IF OPTION = 1, AN ITEM INQUIRY MENU IS WRITTEN TO 
026100* TO SCREEN. IF OPTION = 2, A CUSTOMER INQUIRY MENU IS 


026200* WRITTEN TO THE 
026300* 


SCREEN. 


+ + FF FF HF HF 


O26 40D kx KKK A KAKA KKK KKK KER RK RRR ERE ER ERR RRR ER RR EKER RRR KER RRR REE RKER ER ERRR 


026500* 
026600 MENU-ROUTINE. 


026700 IF CMD-KEY = "01" 
026800 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 
026900 GO TO END-JOB. 


027000 IF OPTION = "1 


027100 WRITE DSPREC FORMAT IS "ITMMNU" 


027200 ELSE 


027300 WRITE DSPREC FORMAT IS "DTLMNU". 


027400 MENU-EXIT. 
027500 EXIT. 
027600/ 


O27 TOD KAR KAA KKK AKA KK KEKE RRR RR RK EKER ERR KERR ER RR ER ER RRR ER ERE REE ER ERR RE 


027800* 
027900* 
028000* 


ITEM INQUIRY 


028100* THE ITEM NUMBER REQUESTED BY THE USER ON THE ITEM INQUIRY 


028200* SCREEN IS CHECKED. THIS IS DETERMINED BY THE 


028300* DISPLAY RECORD FORMAT BEING PROCESSED - IN THIS CASE IT 


028400* 


028500* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. 


IF CMD 


028600* IS PRESSED, THE ITEM INQUIRY REQUEST IS CANCELED, AND 1 


028700* MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 


028800« 


028900* IF AN ITEM NUMBER IS ENTERED, AN ITEM INQUIRY REQUEST IS 


029000* SENT TO THE AP 


029100* IS SELECTED BASED ON THE ITEM NUMBER REQUESTED. 


029200* 


ICF Programming V4R1 


TMMNU. 


KEY 2 
THE 


PROPRIATE REMOTE SYSTEM. THE REMOTE SYS] 


TEM 


* + FF FF FF HF HF FF HF HF 
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029300* A CHECK IS MADE FOR THREE CONDITIONS FOLLOWING THE READ. * 
029400* 1) THE REMOTE SYSTEM TIMED OUT, 2) NO DATA RECEIVED, AND * 
029500* 3) DATA RETURNED IN AN UNEXPECTED RECORD FORMAT. * 
029600* * 
029700* IF THE REMOTE SYSTEM TIMES OUT (MAJ-MIN = 0310) A MESSAGE * 
029800* IS WRITTEN TO THE SCREEN, ASKING TO TRY AGAIN OR END THE * 
029900* PROGRAM. * 
030000* * 
030100* IF NO DATA IS RECEIVED AFTER THE READ OPERATION TO THE * 
030200* PROGRAM DEVICE (MAJ-MIN = 03 ) THE REQUEST IS SENT AGAIN * 
030300* TO THE REMOTE SYSTEM AND THE READ OPERATION IS ISSUED TO * 
030400* THE PROGRAM DEVICE. * 
030500* * 
030600* IF THE RECORD RETURNS WITH THE WRONG RECORD FORMAT, THE * 
030700* PROGRAM WILL GO TO EXIT-FORMAT-ERR ROUTINE. * 
030800* * 
OZ O09 OO KARR AA KKK AKKK KK KEKE KEKE KKK ERE E RRR RRR KERR RR ERE KERR KER RR EREREREREREER RE 
031000* Ey 


031100 ITMIN-ROUTINE. 
031200 IF CMD-KEY = "01" 


031300 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 
031400 GO TO END-JOB. 

031500 IF CMD-KEY = "02" 

031600 WRITE DSPREC FORMAT IS "CIMENU" 

031700 GO TO ITMIN-EXIT. 

031800 MOVE CORR ITMMNU-I TO ITMREQ. 


** CORRESPONDING items for statement 266: 
ak ITEMNO 
* ** End of CORRESPONDING items for statement 266 

031900 IF ITEMNO OF ITMMNU-I LESS THAN 399999 GO TO XICFO1. 
032000 IF ITEMNO OF ITMMNU-I LESS THAN 699999 GO TO XICFO2. 
032100 IF ITEMNO OF ITMMNU-I LESS THAN 899999 GO TO XICFO3. 
032200 XICFO1. 
032300 OVE "ICFO1 "TO PGM-DEV-NME. 
032400 GO TO XITMIN. 
032500 XICFO2. 
032600 OVE "ICFO2 "TO PGM-DEV-NME. 
032700 GO TO XITMIN. 
032800 XICFO3. 


032900 OVE "ICFO3  " TO PGM-DEV-NME. 
033000 XITMIN. 

033100 OVE ZEROS TO CMNF-INDIC-AREA. 

033200 WRITE CMNREC FORMAT IS "ITMREQ" 
033300 TERMINAL IS PGM-DEV-NME. 


033400 TRY-AGAIN. 
033500 READ CMNFIL. 
033600 IF MAJ-MIN = "0310" 


033700 WRITE DSPREC FORMAT IS "TIMOUT" 

033800 READ DSPFIL INDICATORS ARE DSPF-INDIC-AREA 

033900 IF TIMRSP = "1" GO TO TRY-AGAIN END-IF 

034000 IF TIMRSP = "2" GO TO END-JOB END-IF. 

034100 IF MAJ = "03" 

034200 GO TO XITMIN. 

034300 IF RCD-FMT-NME IS NOT EQUAL "ITMRSP" GO TO EXIT-FORMAT-ERR. 


034400 PERFORM ITMOUT-ROUTINE THRU ITMOUT-EXIT. 
034500 ITMIN-EXIT. 

034600 EXIT. 

034700/ 
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O34B OO KKK KKK RK AK AKER KR KAKA KER RR KAKI KIRK KAKI KI KIKI KIKI RIK IARI KIKI KIARA 


034900* * 
035000* PROCESS ITEM INFORMATION * 
035100* * 
035200* THE ITEM RECORD RECEIVED FROM THE TARGET PROGRAM AND THE * 
035300* INFORMATION ABOUT THE ITEM IS PROCESSED AND DISPLAYED. * 
035400* IF ITEMNO IS @ OR LESS, IT IS AN INVALID REQUEST AND A FRESH * 
035500* ITEM MENU IS WRITTEN TO THE SCREEN. IF THE REQUEST IS * 
035600* VALID, VALUES ARE CALCULATED BASED ON THE INFORMATION * 
035700* RECEIVED. * 
035800* * 
C359 OQ ee AA KAKA KEK KAKA KKK AKER EKER ERE KKK KKK KEKE ERR EERE RRR KKK EERE RE RERER RRR A 
036000 

036100 ITMOUT-ROUTINE. 

036200 IF ITEMNO OF ITMRSP NOT GREATER THAN 0 

036300 WRITE DSPREC FORMAT IS "ITMMNU" 

036400 GO TO ITMOUT-EXIT. 

036500 OVE DESC TO DSC OF ITMSC2-0. 

036600 OVE QTYLST TO QAVAIL OF ITMSC2-0. 

036700 OVE QTYOO TO QTYO OF ITMSC2-0. 

036800 OVE QTYOH TO QTYH OF ITMSC2-0. 

036900 OVE QTYBO TO QTYB OF ITMSC2-0. 

037000 MOVE UNITQ TO UNT OF ITMSC2-0. 

037100 OVE PRQ1 TO PR1 OF ITMSC2-0. 

037200 OVE PRQ@5 TO PR5 OF ITMSC2-0. 

037300 OVE UFRT TO UFR OF ITMSC2-0. 

037400 WRITE DSPREC FORMAT IS "ITMSC2" 

037500 INDICATORS ARE DSPF-INDIC-AREA. 

037600 ITMOUT-EXIT. 

037700 EXIT. 

037800* 

037 OQ ea KAKA KK KEK KEKK KKK KKK KERR ER ERK KKK RRR KEK ERR EERE KR KKK ERE RRR ERERER EK 
038000* * 
038100* ADDITIONAL ITEM INFORMATION * 
038200* * 
038300* ADDITIONAL ITEM INFORMATION IS PROCESSED AND THE RESULT * 
038400* DISPLAYED ON THE SCREEN WHEN A RESPONSE IS READ FROM THE * 
038500* DISPLAY STATION WITH AN ITEM SCREEN RECORD FORMAT. * 
038600* * 
038700* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. IF CMD KEY 2 * 
038800* IS PRESSED, THE ITEM INQUIRY IS ENDED, AND THE MAIN MENU * 
038900* (CIMENU) IS WRITTEN TO THE SCREEN. IF CMD KEY 3 IS PRESSED, * 
039000* THE ITEM INQUIRY MENU IS WRITTEN TO THE SCREEN. BY PRESSING * 
039100* ENTER WHEN SCREEN 2 IS DISPLAYED, MORE INFORMATION (PROFIT-  * 
039200* LOSS) IS WRITTEN TO THE SCREEN. IF SCREEN 3 IS DISPLAYED, * 
039300* PRESSING ENTER WILL CAUSE THE ITEM INQUIRY MENU TO BE * 
039400* WRITTEN TO THE SCREEN. * 
039500* * 
OZ 96 OD KAA KAA K KKK AKER EKER RRR ERR ER REK RRR KERR ER EK RRR KER RRR REE RE RE RERR RE 
039700* 

039800 ITMRTN-ROUTINE. 

039900 IF CMD-KEY = "01" 

040000 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 

040100 GO TO END-JOB. 

040200 IF CMD-KEY = "02" 

040300 WRITE DSPREC FORMAT IS "CIMENU" 

040400 GO TO ITMRTN-EXIT. 

040500 IF CMD-KEY = "03" 

040600 WRITE DSPREC FORMAT IS "ITMMNU" 

040700 GO TO ITMRTN-EXIT. 

040800 IF RCD-FMT = "ITMSC2" 

040900 PERFORM PROFIT-LOSS THRU PROFIT-LOSS-EXIT 

041000 WRITE DSPREC FORMAT IS "ITMSC3" 

041100 GO TO ITMRTN-EXIT. 

041200 WRITE DSPREC FORMAT IS "ITMMNU". 

041300 ITMRTN-EXIT. 

041400 EXIT. 

041500* 
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16.002 I IOI I ICR ICE ICI I ICR ICICI ICICI ICICI RII A IR IIR ACR A 
1700* * 
1800* PROFIT AND LOSS FIGURES ARE CALCULATED FOR THE ITEM NUMBER * 
1900* REQUESTED. THESE ARE USED IN SCREEN 2 OF THE ITEM. * 
2000* * 
2.10022 I IOI IO IOI ICG I I ICICI I ICR ICR ICICI ICI I ICICI RI IR A IIR A 


2200* 
2300 PROFIT-LOSS. 
2400% Ey 
2500 SUBTRACT SLSTM FROM CSTTM GIVING PROFM. 
2600 ULTIPLY PROFM BY 100 GIVING PROFM. 
2700 IF SLSTM GREATER THAN 0 
2800 DIVIDE PROFM BY SLSTM GIVING PROFM. 
2900 ULTIPLY QTYLST BY PRO1 GIVING LOSTS. 
3000 OVE SLSTM TO SLSM. 
3100 OVE SLSTY TO SLSY. 
3200 OVE CSTTM TO CSTM. 
3300 OVE PROFM TO PROFIT. 
3400 OVE CSTTY TO CSTY. 
3500 PROFIT-LOSS-EXIT. 
3600 EXIT. 
3700/ 
ZEOOQ KAA AKA A KKK ERK AK KKK KERR KERR RRR RRR ERR KER ERE RRR ERR KER EKER ERE RR ER ERE RERER 
3900* * 
4000* CUSTOMER INQUIRY * 
4100* * 
4200* THE REQUEST FROM THE CUSTOMER INQUIRY MENU IS PROCESSED. * 
4300* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. IF CMD KEY 2 * 
4400* IS PRESSED, THE MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. * 
4500* * 
4600* IF A CUSTOMER NUMBER IS ENTERED, THE CUSTOMER INQUIRY * 
4700* REQUEST IS SENT TO THE REMOTE SYSTEM. THEN DTOUT-ROUTINE * 
4800* THRU DTOUT-EXIT ARE PERFORMED. * 
4900* * 
FOOD KAKA AK KAA KKK KKK KKK KERR KEK RRR KERR RRR EKER RRR RRR RRR ERR ERK ER ERE RRERERERE 
5100+ FR 
5200 DTLIN-ROUTINE. 
5300 IF CMD-KEY = "Q1" 
5400 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 
5500 GO TO END-JOB. 
5600 IF CMD-KEY = "02" 
5700 WRITE DSPREC FORMAT IS "CIMENU" 
5800 GO TO DTLIN-EXIT. 
5900 EVDTL. 
6000 OVE "ICFOO " TO PGM-DEV-NME. 
6100 OVE CORR DTLMNU-I TO DTLREQ. 

** CORRESPONDING items for statement 341: 

#k CUSTNO 

*x End of CORRESPONDING items for statement 341 
6200 OVE ZEROS TO CMNF-INDIC-AREA. 
6300 WRITE CMNREC FORMAT IS "DTLREQ" 
6400 TERMINAL IS PGM-DEV-NME. 
6500 PERFORM DTOUT-ROUTINE THRU DTOUT-EXIT. 
6600 DTLIN-EXIT. 
6700 EXIT. 
6800* 
BIODOD KAKA KKK AAR KK KKK KKK KERR RRR ERK RR KERR RRR RRR RR KR RRR ERR RR KER ERE RERE REE 
7000* * 
7100* PROCESS CUSTOMER INFORMATION * 
7200* * 
7300* THE CUSTOMER DATA RECEIVED FROM THE TARGET PROGRAM IS * 
7400* PROCESSED. IF CUSTOMER NUMBER IS ZERO OR LESS, IT IS AN * 
7500* INVALID REQUEST AND THE MAIN MENU IS WRITTEN TO THE SCREEN. ~* 
7600* * 


TT OO KKK KKK KKK KEKE KKK EKER RRR RRR RRR RRR KERR RRR ER KERR RRR RR RR RRR ERR RERE REE 
7800* 

7900 DTOUT-ROUTINE. 

8000 IF CUSTNO OF DTLRSP-I NOT GREATER THAN 0 

8100 WRITE DSPREC FORMAT IS "CIMENU" 

8200 GO TO DTOUT-EXIT. 

8300 PERFORM CUSTOMER-DETAIL THRU CUSTOMER-DETAIL-EXIT. 
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O48 7 OD % ke KK KKK RK AKA KER KR KAKA KR KR KAKA KI KER IA KI KIRK KAKI KIKI KEIRA KIRK IARI K 


THIS ROUTINE HANDLES THE USER'S REQUEST FOLLOWING THE DISPLAY 


CMD KEY 2 WILL DISPLAY THE MAIN MENU, AND "ENTER" WILL BRING 


. (CMD KEY 1 WILL EXIT THE JOB, 


U. 


+ + FF F 


C494 OD RAK KAA KKK AK KA KK KEKE KEKE RRR KEKE KERR RRR ERE RE RE ERRRERERERERERERERERER RE 


HRU DETACH-EXIT 


CIMENU" 


MNU" . 


C507 OD RAK KAA KKK AKA AKER ERR ERK ERR ER EK ERE KER RR ERE RRREKERER ERE ERE ER ERERE 


ROGRAM DEVICE IS ISSUED. 
ONDITIONS FOLLOWING THE READ. 
OUT, 2) NO DATA RECEIVED, AND 
PECTED RECORD FORMAT. 


OUT (MAJ-MIN = 0310) A MESSAGE 
SKING TO TRY AGAIN OR END THE 


R THE READ OPERATION TO THE 
3__ ) THE REQUEST IS SENT AGAIN 
E READ OPERATION IS ISSUED TO 


THE WRONG RECORD FORMAT, THE 
MAT-ERR ROUTINE. 


* + FF FF HF HF HF FF HF HF FHF FF FF HF 


C526 OOK AK KAA KKK A KKK K KEKE KKK KKK KER ERE RRR R RRR RRR RRR RRR KER ERR REE ERERER RE 


048400 DTOUT-EXIT. 
048500 EXIT. 

048600« 

048800« 

048900« 

049000* OF THE CUSTOMER INFORMATION 
049100« 

049200* UP THE CUSTOMER INQUIRY MEN 
049300« 

049500« 

049600 DTLRTN-ROUTINE. 

049700 IF CMD-KEY = "Q1" 

049800 PERFORM DETACH-ROUTINE T 
049900 GO TO END-JOB. 

050000 IF CMD-KEY = "92" 

050100 WRITE DSPREC FORMAT IS " 
050200 GO TO DTLRTN-EXIT. 
050300 WRITE DSPREC FORMAT IS "DTLI 
050400 DTLRTN-EXIT. 

050500 EXIT. 

050600* 

050800* 

050900* | THE READ OPERATION TO THE P 
051000* | A CHECK IS MADE FOR THREE C 
051100* 1) THE REMOTE SYSTEM TIMED 
051200* 3) DATA RETURNED IN AN UNEX 
051300* 

051400* IF THE REMOTE SYSTEM TIMES 
051500* IS WRITTEN TO THE SCREEN, A 
051600* PROGRAM. 

051700* 

051800* IF NO DATA IS RECEIVED AFTE 
051900* | PROGRAM DEVICE (MAJ-MIN = 0 
052000* TO THE REMOTE SYSTEM AND TH 
052100* THE ICF PROGRAM DEVICE. 
052200* 

052300* IF THE RECORD RETURNS WITH 
052400* PROGRAM WILL GO TO EXIT-FOR 
052500* 

052700* 

052800* 

052900 CUSTOMER-DETAIL. 

053000 MOVE ZEROS TO CMNF-INDIC-AR 
053100 READ CMNFIL. 

053200 IF MAJ-MIN = "310" 

053300 WRITE DSPREC FORMAT IS " 
053400 READ DSPFIL INDICATORS A 
053500 IF TIMRSP = "1" GO TO CU 
053600 IF TIMRSP = "2" GO TO EN 
053700 IF MAJ = "03" 

053800 MOVE ZEROS TO CMNF-INDIC 
053900 WRITE CMNREC FORMAT IS " 
054000 TERMINAL IS PGM-DEV-N 
054100 GO TO CUSTOMER-DETAIL. 
054200 IF RCD-FMT-NME IS NOT EQUAL 
054300 MOVE CUSTNO OF DTLRSP-I TO 
054400 MOVE DNAME OF DTLRSP-I TO C 
054500 MOVE DLSTOR OF DTLRSP-I TO 
054600 MOVE DSLSTM OF DTLRSP-I TO 
054700 MOVE DSPMQ1 OF DTLRSP-I TO 
054800 MOVE DSPMQ2 OF DTLRSP-I TO 
054900 MOVE DSTTYD OF DTLRSP-I TO 
055000 MOVE IDEPT OF DTLRSP-I TO D 
055100 WRITE DSPREC FORMAT IS "DTL 
055200 CUSTOMER-DETAIL-EXIT. 

055300 EXIT. 

055400/ 
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EA. 


TIMOUT" 

RE DSPF-INDIC-AREA 
STOMER-DETAIL END-IF 
D-JOB END-IF. 


-AREA 
DTLREQ" 
E 


CUSTN OF DTLSCR-O. 
AME OF DTLSCR-O. 
DLSTR OF DTLSCR-O. 
DSLSM OF DTLSCR-O. 
DSPM1 OF DTLSCR-O. 
DSPM2 OF DTLSCR-O. 
DSTYD OF DTLSCR-O. 
EPT OF DTLSCR-O. 
SCR". 


"DTLRSP" GO TO EXIT-FORMAT-ERR. 
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C555 OOD KAR KAA KKK AK KA AK KEKE RRR ERK RRR ER EKER KR RR RE RE ERRKRERRERERREKRRERREREER RE 


055600* * 
055700* THE EVOKE-ROUTINE IS CALLED TO EVOKE THE TARGET PROGRAM. * 
055800* THE SAME TARGET PROGRAM (ICFLIB/CTDMULCL) IS EVOKED AT * 
055900* | FOUR DIFFERENT REMOTE SYSTEMS. THE PROGRAM DEVICE e 
056000* IDENTIFIES WHICH SESSION SHOULD BE EVOKED. THE PROGRAM * 
056100* | DEVICE WAS SPECIFIED IN CMID PRIOR TO CALLING THIS ROUTINE. * 
056200* * 
C56 300 Kx KAA KKAAKKK KKK KEKE RRR ERE RREK RRR KER ERE KER RRR ERE RRR ER ERE ER ERRRE 
056400* 

056500* 

056600 EVOKE-ROUTINE. 

056700 OVE "CTDMULCL" TO PGMID OF EVKREQ-0. 

056800 OVE "ICFLIB" TO LIB OF EVKREQ-0. 

056900 OVE "ICFO@ " TO PGM-DEV-NME 

057000 WRITE CMNREC FORMAT IS "EVKREQ" 

057100 TERMINAL IS PGM-DEV-NME. 

057200 OVE "ICFO1  " TO PGM-DEV-NME 

057300 WRITE CMNREC FORMAT IS "EVKREQ" 

057400 TERMINAL IS PGM-DEV-NME. 

057500 OVE "ICFO2  " TO PGM-DEV-NME 

057600 WRITE CMNREC FORMAT IS "EVKREQ" 

057700 TERMINAL IS PGM-DEV-NME. 

057800 OVE "ICFO3  " TO PGM-DEV-NME 

057900 WRITE CMNREC FORMAT IS "EVKREQ" 

058000 TERMINAL IS PGM-DEV-NME. 

058100 EVOKE-EXIT. 

058200 EXIT. 

058300* 

C584 00 4 xx KARR KARR KARR RK EKER ERK KEK RRR RRR RRR KER ERE RRR RRR KER ERE REE ER EERE 
058500* * 
058600* THE TRANSACTION AND SESSION ARE ENDED FOR EACH OF THE * 
058700* REMOTE SYSTEMS. * 
058800* * 
C5 B9OD KAR KAA KKK AKER KERR KEKE KKK ERR ER EKER RRR RRR EKER RR KR RRR ERE ERE ER ERR RE 
059000« 


059100 ERROR-RECOVERY. 

059200 PERFORM DETACH-ROUTINE THRU DETACH-EXIT. 
059300 CLOSE CMNFIL DSPFIL 

059400 QPRINT. 

059500 MOVE "O" TO ERR-SW. 

059600 ERROR-RECOVERY-EXIT. 

059700 EXIT. 


C5 IBOOK aK AAR KAA KKK KK KEKE KEK RRR KERR RRR RRR RRR KERR RE REK RR RKEER ERR ERE ERERER RR 


059900* * 
060000* EXIT-FORMAT-ERR IS PERFORMED WHEN A READ TO CMNFIL RETURNS WITH * 
060100* AN UNEXPECTED RCD-FMT-NME IN THE I-O0-FEEDBACK AREA FOR CMNFIL. * 
060200* AN ERROR MESSAGE IS PRINTED AND THE PROGRAM ENDS. * 
060300* * 
QBO4 OD Kae KARR ARK KARR K KEK RRR KKK RRR RRR RRR KER ERE REK RR RKERERRREREREREREER RE 
060500* 


060600 EXIT-FORMAT-ERR. 

060700 MOVE MAJ-MIN TO RC. 

060800 MOVE "RECORD FORMAT IS INCORRECT ON READ 7 
060900 TO ERRMSG. 

061000 WRITE PRINTREC. 

061100 CLOSE CMNFIL DSPFIL QPRINT. 

061200 STOP RUN. 

061300* 
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061500* * 
061600* THIS ROUTINE IS CALLED TO END THE TRANSACTION WITH THE * 
061700* REMOTE SYSTEM. * 
061800* * 
OB 1LIOD KAKA AK KARR ARK RK K KEKE RRR RRR E KEKE RRR ERE RE REE RRR ER RRR REE REE ER EERE 
062000* 
062100 DETACH-ROUTINE. 
404 062200 MOVE "ICFOQ " TO PGM-DEV-NME 
405 062300 WRITE CMNREC FORMAT IS "DETACH" 
062400 TERMINAL IS PGM-DEV-NME. 
406 062500 MOVE "ICFO1 " TO PGM-DEV-NME 
407 062600 WRITE CMNREC FORMAT IS "DETACH" 
062700 TERMINAL IS PGM-DEV-NME. 
408 062800 MOVE "ICFO2  " TO PGM-DEV-NME 
409 062900 WRITE CMNREC FORMAT IS "DETACH" 
063000 TERMINAL IS PGM-DEV-NME. 
410 063100 MOVE "ICFO3 =" TO PGM-DEV-NME 
411 063200 WRITE CMNREC FORMAT IS "DETACH" 
063300 TERMINAL IS PGM-DEV-NME. 
063400 DETACH-EXIT. 
063500 EXIT. 
063600* 
0637 OD KKK AAR AKA KKK KK KEKE RRR ERK EKER ER REK RRR KERR RE REKRERKEKERRRERERRERRERERERRRE 
063800* * 
063900* THIS ROUTINE IS CALLED TO RELEASE THE PROGRAM DEVICES, END * 
064000* THE SESSION AND END THE PROGRAM. * 
064100* * 
OBA 200 kx KKK A KKK AK KARR KEKE RRR ERK KER RR ER RK ERE KERR RE RRR RRR KER RRR REE RERER RE 
064300* Ey 
064400* 
412 064500 END-JOB. 
413 064600 DROP "ICFOO " FROM CMNFIL. 
414 064700 DROP "ICFO1 " FROM CMNFIL. 
415 064800 DROP "ICFO2 " FROM CMNFIL. 
416 064900 DROP "ICFO3 =" FROM CMNFIL. 
417 065000 CLOSE CMNFIL DSPFIL QPRINT. 
418 065100 STOP RUN. 
065200* 
eee ee END OF SOURCE ** * * * 
* 25 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005200 
Message... .: o INPUT fields found for format DETACH. 
* 25 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005200 
Message... . 3: o INPUT fields found for format EOS. 
* 25 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005200 
Message... . 3: o INPUT fields found for format EVKREQ. 
* 80 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005600 
Message... . 3: o OUTPUT fields found for format CIMENU. 
* 80 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005600 
Message... .: o OUTPUT fields found for format DTLMNU. 
* 80 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005600 
Message... . 3: o OUTPUT fields found for format ITMMNU. 
* 80 MSGID: LBLQ600 SEVERITY: 10 SEQNBR: 005600 
Message... . 3: o OUTPUT fields found for format TIMOUT. 
ee ee * END OF MESSAGES * * * * * 
Message Summary 
Total Info(0-4) Warning(5-19) Error(20-29) Severe (30-39) Terminal (40-99) 
7 0 7 ) 0 
Source records read... .....: 652 
Copy records read... .. 2... 23: 171 
Copy members processed ......: 2 
Sequence errors. .........: @ 
Highest severity message issued. . : 10 


OB LAOD kx x KAA KK ARK KARR RAK KEKE RRR ERR E RRR RRR KERR RE RRR RRR RRR ER ER ERE ER ERRRE 


LBLO901 00 Program CSDMUL created in library ICFLIB. 
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eee * * END OF COMPILATION ** * * * 
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Program ..... 2. ee 

Library ....... 
Source file ...... 

LTDRAnYy eG eee ee 
Source member ..... 
Generation severity level 
Text ‘description’... 


Scare’ Iie Dats ets CSFMUL 

USGL GSS Bo Ade £8. ICFLIB 

Sad: Ge ders 8 QICFPUB 

etaues) Bs Mee Bro de ICFLIB 

eee ee et CSFMUL 10/03/90 14:26:2 
#. oo8 Goad 29 


7 


. ss... 2 CBL Multiple Session Inquiry - Source $$ 


Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........:  *NOMAX 
Message limit severity ......: 29 
Print file... ...... 2... 2:  QSYSPRT 
MET AVAY ©” oes ibs Sen St coke ated ciocechs teak cap etn *LIBL 
FIPS flagging .......... 2 *NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ......... +... : + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release. . 2... . 2... 3) *CURRENT 
User profile. ........... :  *USER 
Authority™ sos apa ae Soe oe 8 *LIBCRTAUT 
Compiler. .......... 4. 2 IBM AS/400 COBOL/400 
1 Q00100 IDENTIFICATION DIVISION. 10/01/87 
2 000200 PROGRAM-ID. CSFMUL. 10/01/87 
OQOO3 OD kx xR AAR ARK KARR KKK KEK ERK ER EKER ERR RRR ERE RRR EK RRR KER RRR REE REE ER ERR RE 10/01/87 
000400* THIS PROGRAM ASSIGNS FOUR SESSIONS AS FOLLOWS: * 10/01/87 
000500*  'ICFOO' TO INQUIRE ABOUT A CUSTOMER ACCOUNT BEFORE AN * 10/01/87 
000600* ORDER IS PROCESSED. * 10/01/87 
000700* "ICFO1' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 10/01/87 
000800 BEING ORDERED (ITEM 000001 THRU 399999). * 10/01/87 
000900* "ICFO2Z' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 10/01/87 
001000* BEING ORDERED (ITEM 400000 THRU 699999). * 10/01/87 
001100* "ICFO3' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 10/01/87 
001200* BEING ORDERED (ITEM 700000 THRU 999999). * 10/01/87 
001300* A DISPLAY DEVICE IS USED TO ENTER THE REQUEST ( USING A * 10/01/87 
001400* CUSTOMER AND AN ITEM MENU) THAT IS SENT TO THE REMOTE * 10/01/87 
001500* SYSTEM. * 10/15/87 
OO LO OO kx KAA KKAAKK ARK RAK KEKE RRR ERE RE RRR RRR KER ERE RRR RRR KERR ERR REE REE REER ER 10/01/87 
3 001700 ENVIRONMENT DIVISION. 10/01/87 
4 001800 CONFIGURATION SECTION. 10/01/87 
5 001900 SOURCE-COMPUTER. IBM-AS400. 01/15/88 
6 002000 OBJECT-COMPUTER. IBM-AS400. 01/15/88 
7 002100 SPECIAL-NAMES. I-0-FEEDBACK IS I0-FEEDBACK 10/01/87 
8 002200 OPEN-FEEDBACK IS OPEN-FBA. 10/01/87 
9 002300 INPUT-OUTPUT SECTION. 10/01/87 
10 002400 FILE-CONTROL. 10/01/87 
002500+ fq 10/14/87 
COZ 6 OO kx KKK ARK AAR KARR RAKE RRR RRR KERR RR ERE KERR KER ERE KERR RRR RRR ERE ERE ER ERE RE 10/01/87 
002700* * 10/01/87 
002800* FILE SPECIFICATIONS * 10/01/87 
002900* * 10/01/87 
003000* CMNFIL : ICF FILE USED TO SEND A REQUEST TO ONE * 10/03/90 
003100* OF FOUR DIFFERENT TARGET PROGRAMS. MULTIPLE * 10/01/87 
003200* SESSIONS ARE ACTIVE CONCURRENTLY. * 10/01/87 
003300* * 10/01/87 
003400* DSPFIL : DISPLAY FILE USED TO ENTER A REQUEST TO BE * 10/14/87 
003500* SENT TO A REMOTE SYSTEM. * 10/01/87 
003600* * 10/01/87 
0037 OD KAKA AK KA ARK A KK KEKE KEK ERK R EKER RK RRR KER ERE KEKE RRR ERE RRR EKER ERE RREER ER 10/01/87 
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11 003800 SELECT CMNFIL ASSIGN TO WORKSTATION-CMNFIL-SI 10/08/87 
12 003900 ORGANIZATION IS TRANSACTION 10/01/87 
13 004000 CONTROL-AREA IS TR-CTL-AREA 10/01/87 
14 004100 FILE STATUS IS STATUS-IND MAJ-MIN. 10/01/87 
15 004200 SELECT DSPFIL ASSIGN TO WORKSTATION-DSPFIL 10/08/87 
16 004300 ORGANIZATION IS TRANSACTION 10/01/87 
17 004400 CONTROL-AREA IS DISPLAY-FEEDBACK 10/01/87 
18 004500 FILE STATUS IS STATUS-DSP. 10/01/87 
19 004600 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 10/01/87 
20 004700 DATA DIVISION. 10/01/87 
21 004800 FILE SECTION. 10/01/87 
22 004900 FD CMNFIL 10/08/87 
23 005000 LABEL RECORDS ARE STANDARD. 10/01/87 
24 005100 01 CMNREC. 10/01/87 
25 005200 05 ITMRSP. 10/01/87 
26 005300 07 RECITM PIC X. 10/01/87 
27 +005400 07 ITEMNO PIC 9(6). 10/01/87 
28 005500 07 DESC PIC X(30). 10/01/87 
29 005600 07 QTYLST PIC 9(7). 10/01/87 
30 005700 07 QTYOH PIC 9(7). 10/01/87 
31 005800 07 QTYOO PIC 9(7). 10/01/87 
32 005900 07 QTYBO PIC 9(7). 10/01/87 
33 006000 07 UNITQ PIC 99. 10/01/87 
34 006100 07 PRO1 PIC 9(5)V99. 10/01/87 
35 006200 07 PRO5 PIC 9(7). 10/01/87 
36 006300 07 UFRT PIC 999V99. 10/01/87 
37 006400 07 SLSTM PIC 9(7)V99. 10/01/87 
38 006500 07 SLSTY PIC 9(9)V99. 10/01/87 
39 006600 07 CSTTM PIC 9(7)V99. 10/01/87 
40 006700 07 CSTTY PIC 9(9)V99. 10/01/87 
41 006800 07 PRO PIC 999V99. 10/01/87 
42 006900 07 LOS PIC 9(7)V99. 10/01/87 
43 007000 07 FILL1 PIC X(56). 10/01/87 
44 007100 05 ITMREQ REDEFINES ITMRSP. 10/01/87 
45 007200 07 LNGTH PIC 9(4). 02/22/89 
46 007300 07 ITEMNO PIC 9(6). 10/01/87 
47 007400 05 DTLREQ REDEFINES ITMRSP. 10/01/87 
48 007500 07 LNGTH PIC 9(4). 02/22/89 
49 007600 07 CUSTNO PIC 9(6). 10/01/87 
50 007700 05 DTLRSP REDEFINES ITMRSP. 10/01/87 
51 007800 07 RECCUS PIC X. 10/01/87 
52 007900 07 CUSTNO PIC 9(6). 10/01/87 
53 008000 07 DNAME PIC X(30). 10/01/87 
54 008100 07 DLSTOR PIC 9(6). 10/01/87 
55 008200 07 DSLST PIC 9(9). 10/01/87 
56 008300 07 DSPMO1 PIC 9(9). 10/01/87 
57 008400 07 DSPMO2 PIC 9(9). 10/01/87 
58 008500 07 DSPMO3 PIC 9(9). 10/01/87 
59 008600 07 DSTTYD PIC 9(11). 10/01/87 
60 008700 07 IDEPT PIC 999. 10/01/87 
61 008800 07 FILL2 PIC X(57). 10/01/87 
62 008900 05 EVKREQ REDEFINES ITMRSP. 10/01/87 
63 009000 07 PGMID PIC X(8). 10/01/87 
64 009100 07 FILLER PIC X(16). 10/01/87 
65 009200 07 LIB PIC X(8). 10/01/87 
66 009300 07 FILLER PIC X(20). 10/01/87 
67 009400 07 LNGTH PIC 9(4). 02/22/89 
68 009500 FD DSPFIL 10/08/87 
69 009600 LABEL RECORDS ARE STANDARD. 10/01/87 
70 009700 01 DSPREC. 10/01/87 
71 009800 COPY DDS-ALL-FORMATS-I-0 OF DSPFIL. 10/08/87 
72 +000001 @5 DSPFIL-RECORD PIC X(79). <-ALL-FMTS 
+000002* INPUT FORMAT: CIMENU FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000003* MENU FOR INQUIRY <-ALL-FMTS 
73 +000004 05 CIMENU-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
74 +000005 06 CIMENU-I-INDIC. <-ALL-FMTS 
75 +000006 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 
76 +000007 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 
77 +000008 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 
78 +000009 06 OPTION PIC X(1). <-ALL-FMTS 
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+000010* OUTPUT FORMAT: CIMENU 


+000011* 
+000012* 
+000013* 
+000014* 
+000015 
+000016 
+000017 
+000018 
+000019 
+000020 
+000021* 
+000022* 
+000023* 
+000024* 
+000025* 
+000026 
+000027 
+000028 
+000029 
+000030 
+000031* 
+000032* 
+000033 
+000034 
+000035 
+000036 
+000037 
+000038 
+000039 
+000040 
+000041 
+000042 
+000043* 
+000044* 
+000045 
+000046 
+000047 
+000048 
+000049 
+000050 
+000051* 
+000052* 
+000053* 
+000054* 
+000055* 
+000056 
+000057 
+000058 
+000059 
+000060 
+000061* 
+000062* 
+000063 
+000064 
+000065 
+000066 
+000067 
+000068 
+000069 
+000070 
+000071 
+000072 
+000073* 
+000074* 
+000075 
+000076 
+000077 
+000078 
+000079 


05 


INPUT FORMAT: DTLMNU 


05 


OUTPUT FORMAT : DTLMNU 


05 


INPUT FORMAT:DTLSCR 


05 


OUTPUT FORMAT:DTLSCR 


05 


INPUT FORMAT: ITMMNU 


05 


OUTPUT FORMAT: ITMMNU 


05 


INPUT FORMAT: ITMSC2 


05 


OUTPUT FORMAT: ITMSC2 


05 


INPUT FORMAT: ITMSC3 


05 


FROM FILE DSPFIL 
MENU FOR INQUIRY 
REDEFINES DSPFIL-RECORD. 
FROM FILE DSPFIL 


CIMENU-O 


DTLMNU-I REDEFINES DSPFIL-RECORD. 

06 DTLMNU-I-INDIC. 
07 IN99 PIC 1 INDIC 99. 
07 IN98 PIC 1 INDIC 98. 
07 IN97 PIC 1 INDIC 97. 

06 CUSTNO PIC S9(6). 


FROM FILE DSPFIL 
DTLMNU-O REDEFINES DSPFIL-RECORD. 
FROM FILE DSPFIL 
CUSTOMER INQUIRY SCR. #2 


DTLSCR-I REDEFINES DSPFIL-RECORD. 

06 DTLSCR-I-INDIC. 
07 IN99 PIC 1 INDIC 99. 
07 IN98 PIC 1 INDIC 98. 
07 IN97 PIC 1 INDIC 97. 


FROM FILE DSPFIL 
CUSTOMER INQUIRY SCR. #2 


DTLSCR-0 REDEFINES DSPFIL-RECORD. 
06 CUSTN PIC X(6). 
06 DEPT PIC $9(3). 
06 DLSTR PIC S9(6). 
06 DSLSM PIC S$9(9). 
06 DSPM1 PIC S9(9). 
06 DSPM2 PIC S9(9). 
06 DSPM3 PIC S9(9). 
06 DSTYD PIC $9(11). 
06 CNAME PIC X(5). 
FROM FILE DSPFIL 
ITEM INQUIRY SCREEN ONE 
ITMMNU-I REDEFINES DSPFIL-RECORD. 
06 ITMMNU-I-INDIC. 
07 IN99 PIC 1 INDIC 99. 
07 IN98 PIC 1 INDIC 98. 
07 IN97 PIC 1 INDIC 97. 
06 ITEMNO PIC S9(6). 
FROM FILE DSPFIL 


ITEM INQUIRY SCREEN ONE 
REDEFINES DSPFIL-RECORD. 

FROM FILE DSPFIL 

ITEM INQUIRY SCREEN TWO 


ITMMNU-O 


ITMSC2-1 REDEFINES DSPFIL-RECORD. 

06 ITMSC2-I-INDIC. 
07 IN99 PIC 1 INDIC 99. 
07 IN98 PIC 1 INDIC 98. 
07 IN97 PIC 1 INDIC 97. 


FROM FILE DSPFIL 
ITEM INQUIRY SCREEN TWO 


ITMSC2-0 REDEFINES DSPFIL-RECORD. 
06 DSC PIC X(30). 

06 QAVAIL PIC S9(7). 

06 QTYH PIC S9(7). 

06 QTYO PIC S9(7). 

06 QTYB PIC S9(7). 

06 UNT PIC X(2). 

06 PR1 PIC $9(5)V9(2). 
06 PR5 PIC S9(7). 

06 UFR PIC $9(3)V9(2). 


FROM FILE DSPFIL 
ITEM INQUIRY SCREEN 3 


ITMSC3-1 REDEFINES DSPFIL-RECORD. 

06 ITMSC3-I-INDIC. 
07 IN99 PIC 1 INDIC 99. 
07 IN98 PIC 1 INDIC 98. 
07 IN97 PIC 1 INDIC 97. 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 
CUSTOMER INQUIRY SCREEN 1 


OF LIBRARY ICFLIB 
CUSTOMER INQUIRY SCREEN 1 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


OF LIBRARY ICFLIB 


rPrerrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrse 


AAAAAANANNANKNANAKNNANAAAAKRAKRAKRAKRAKRANAANANANANNANNANNANANNAAKAAAAAAAKNANAKAANAKAANANANKNNNANNANAAKRAAAA 
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L-FMT 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMT 
L-FMI 
L-FMT 
L-FMT 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMT 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMT 
L-FMIT 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMT 
L-FMT 
L-FMI 
L-FMI 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMT 
L-FMT 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
L-FMI 
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+000080* OUTPUT FORMAT: ITMSC3 FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000081* ITEM INQUIRY SCREEN 3 <-ALL-FMTS 
126 +000082 05 ITMSC3-0 REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
127 +000083 06 SLSM PIC $9(7)V9(2). <-ALL-FMTS 
128 +000084 06 SLSY PIC $9(9)V9(2). <-ALL-FMTS 
129 +000085 06 CSTM PIC $9(7)V9(2). <-ALL-FMTS 
130 +000086 06 CSTY PIC $9(9)V9(2). <-ALL-FMTS 
131 +000087 06 PROFIT PIC $9(3)V9(2). <-ALL-FMTS 
132 +000088 06 LOSTS PIC $9(7)V9(2). <-ALL-FMTS 
+000089* INPUT FORMAT: TIMOUT FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000090* TIME OUT SCREEN <-ALL-FMTS 
133 +000091 05 TIMOUT-I REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
134 +000092 06 TIMOUT-I-INDIC. <-ALL-FMTS 
135 +000093 07 IN99 PIC 1 INDIC 99. <-ALL-FMTS 
136 +000094 07 IN98 PIC 1 INDIC 98. <-ALL-FMTS 
137 +000095 07 IN97 PIC 1 INDIC 97. <-ALL-FMTS 
138 +000096 06 TIMRSP PIC X(1). <-ALL-FMTS 
+000097* OUTPUT FORMAT: TIMOUT FROM FILE DSPFIL OF LIBRARY ICFLIB <-ALL-FMTS 
+000098* TIME OUT SCREEN <-ALL-FMTS 
+000099* 05 TIMOUT-O REDEFINES DSPFIL-RECORD. <-ALL-FMTS 
139 009900 FD QPRINT 10/01/87 
140 010000 LABEL RECORDS ARE OMITTED. 10/01/87 
141 010100 01 PRINTREC. 01/14/88 
142 010200 05 RC PIC 9999. 01/15/88 
143 010300 05 ERRMSG PIC X(128). 01/14/88 
144 010400 WORKING-STORAGE SECTION. 10/01/87 
145 010500 77 STATUS-IND PIC X(2). 10/01/87 
146 010600 77 STATUS-DSP PIC X(2). 10/01/87 
147 010700 77 MAJ-MIN-SAV PIC X(4). 10/01/87 
148 010800 77 EOF-PFILE-SW PIC X VALUE "0". 10/01/87 
149 010900 77 ERR-SW PIC X VALUE "0". 10/01/87 
150 011000 77 INDON PIC 1 VALUE B"1". 10/01/87 
151 011100 77 INDOFF PIC 1 VALUE B"O". 10/01/87 
152 011200 77 OPEN-COUNT PIC 9(1) VALUE 0. 10/01/87 
153 011300 77 LEN PIC 9(10)V9(5) COMP. 10/01/87 
154 011400 77 PROFM PIC 9(7)V9(2) COMP-4. 10/01/87 
155 011500 77 CMD2 PIC X(31) 10/01/87 
156 011600 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 10/01/87 
157 011700 01 TR-CTL-AREA. 10/01/87 
158 011800 05 FILLER PIC X(2). 10/01/87 
159 011900 05 PGM-DEV-NME PIC X(10). 10/01/87 
160 012000 05 RCD-FMT-NME PIC X(10). 10/01/87 
161 012100 01 DSPF-INDIC-AREA. 10/01/87 
162 012200 05 IN23 PIC 1 INDIC 23. 10/01/87 
163 012300 88 IN23-ON VALUE B"1". 10/01/87 
164 012400 88 IN23-OFF VALUE B"0". 10/01/87 
165 012500 05 IN97 PIC 1 INDIC 97. 10/01/87 
166 012600 88 IN97-ON VALUE B"1". 10/01/87 
167 012700 88 IN97-OFF VALUE B"0". 10/01/87 
168 012800 05 IN98 PIC 1 INDIC 98. 10/01/87 
169 012900 88 IN98-ON VALUE B"1". 10/01/87 
170 013000 88 IN98-OFF VALUE B"0". 10/01/87 
171 013100 05 IN99 PIC 1 INDIC 99. 10/01/87 
172 013200 88 IN99-ON VALUE B"1". 10/01/87 
173 013300 88 IN99-OFF VALUE B"0". 10/01/87 
174 013400 01 MAJ-MIN. 10/01/87 
175 013500 05 MAJ PIC X(2). 10/01/87 
176 013600 05 MIN PIC X(2). 10/01/87 
177 013700 01 DISPLAY-FEEDBACK. 10/01/87 
178 013800 05 CMD-KEY PIC X(2). 10/01/87 
179 013900 05 FILLER PIC X(10). 10/01/87 
180 014000 05 RCD-FMT PIC X(10). 10/01/87 
014100/ 10/01/87 
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014200 PROCEDURE DIVISION. 

014300 DECLARATIVES. 

014400* 4 

QO LA5 OQ x eee AK KKK KEK KKK KKK KKK EKER KEKE KKK KKK KEKE EERE RRR KKK KEK KKK ERE RRR ERER EKER 
014600* 

014700* AN ERROR ON THE DISPLAY FILE - DSPFIL - MAKES IT INACTIVE 
014800* AN ERROR MESSAGE IS PRINTED, THE FILES ARE CLOSED AND THE 
014900* PROGRAM IS ENDED. 

015000* 

O15 1 OQ x ee aA KKK K KEKE KKK KKK ERK KER EKER KKK K KER ERR EERE RRR AEKEERE RRR ERER ERE A 
015200* 

015300 DSP-ERROR SECTION. 

015400 USE AFTER STANDARD ERROR PROCEDURE ON DSPFIL. 

015500* 

015600 DSPFIL-EXCEPTION. 

015700 MOVE "DISPLAY ERROR. JOB TERMINATED" TO ERRMSG. 

015800 WRITE PRINTREC. 

015900 CLOSE CMNFIL DSPFIL QPRINT. 

016000 STOP RUN. 

016100* 

016200 CMN-ERROR SECTION. 

016300 USE AFTER STANDARD ERROR PROCEDURE ON CMNFIL. 

016400 CMNFIL-EXCEPTION. 

O16 5 OQ x ee aA KKK K KEK KKK KKK KKK KEKE KER ERE KKK KKK KEKE ERR EERE KEKE KKK RE REE ERER ERE K 
016600* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION * 
016700* MAJOR CODE 34 IS AN INPUT EXCEPTION * 
OLE 800k xx K KKK KAA KARR RARER RK RRR ERE E KERR RRR ERR E RRR ERR ERE RRR ER ERE REERRR 
016900 IF MAJ-MIN = "3431" 

017000* DATA TRUNCATED IN INPUT AREA. SAVE RETURN CODE . 


+ + FF F 


017100 MOVE MAJ-MIN TO MAJ-MIN-SAV 
017200 GO TO EXIT-DECLARATIVES. 
017300* 


017400* RECOVERABLE SESSION ERROR. CLOSE ICF FILE. 
017500 IF MAJ = "83" 


017600 MOVE MAJ-MIN TO RC 

017700 MOVE "PROGRAM STARTED AGAIN DUE TO SESSION ERROR" 
017800 TO ERRMSG 

017900 WRITE PRINTREC 

018000 MOVE "1" TO ERR-SW 

018100 GO TO EXIT-DECLARATIVES. 

018200* 


O1B3 00k xR KKK KARR ARK KE RRR RRR KERR ER ERR RRR ERE RER ER RRR KERR ERERRREREEREER ER 


018400* THIS ROUTINE IS CALLED WHEN THERE IS A PERMANENT SESSION ERROR. * 


018500* GET INFORMATION FROM THE MAJOR-MINOR CODE AND PLACE IT INTO * 
018600* A DATABASE FILE. THEN PRINT THE FILE IN HEX USING COPYFILE. * 
0187 002 a EI IG I IO ICI IIE IC ICI ICICI ICICI I ICR RI ICR ICI IR AIR A 
018800* 


018900 GETFBA. 

019000 MOVE MAJ-MIN TO RC. 

019100 MOVE "PROGRAM TERMINATED DUE TO ERROR IN CMNFIL FILE" 
019200 TO ERRMSG. 

019300 WRITE PRINTREC. 

019400 CLOSE CMNFIL DSPFIL 


019500 QPRINT. 
019600 STOP RUN. 
019700* 


019800 EXIT-DECLARATIVES. 
019900 EXIT. 


020000* 
020100 END DECLARATIVES. 

020200/ 

020300 START-PROGRAM SECTION. 
020400* 

020500 START-PROGRAM-PARAGRAPH. 
020600* 

020700 OPEN I-0 CMNFIL DSPFIL 
020800 QUTPUT QPRINT. 
020900* 
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10/01/87 
10/01/87 
10/14/87 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
10/08/87 
10/05/87 
10/08/87 
10/05/87 
10/08/87 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
10/05/87 
10/14/87 
10/08/87 
10/08/87 
02/22/89 
02/22/89 
02/22/89 
02/22/89 
10/01/87 
10/01/87 
10/01/87 
10/13/87 
10/08/87 
10/03/90 
10/01/87 
01/14/88 
10/01/87 
01/14/88 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
10/01/87 
10/01/87 
01/14/88 
10/08/87 
01/14/88 
10/01/87 
10/08/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
02/28/89 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/14/87 
10/08/87 
10/01/87 
10/01/87 
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(CVANCCC tte re ee ee 


021100* THE FOLLOWING TEST IS TO ATTEMPT RECOVERY IF AN ERROR OCCURS * 


021200* WHEN OPENING THE ICF FILE. * 
O21 300 kK K KKK KARA KKK KKK RRR KER EKER EKER RRR ERE REE RRR ERE RRR ER EKER ER EERE 
021400» Ey 

021500 IF ERR-SW = "1" 

021600 THEN IF OPEN-COUNT IS = 9 

021700 THEN PERFORM DETACH-ROUTINE THRU DETACH-EXIT 

021800 GO TO END-JOB 

021900 ELSE 

022000 ADD 1 TO OPEN-COUNT 

022100 PERFORM ERROR-RECOVERY 

022200 GO TO START-PROGRAM-PARAGRAPH 

022300 ELSE 

022400 MOVE @ TO OPEN-COUNT. 

022500* 


O22 600 KAR KAA KKK AK KA KK KKK KEK ERK KEK EKER EKER RRR RRR EKER RRR KERR ER ER ERE ER EER RR 


022700* * 
022800* THE DISPLAY DEVICE IS IMPLICITLY ACQUIRED WHEN THE * 
022900* FILE IS OPENED. * 
023000* * 
023100* ALL OF THE ICF PROGRAM DEVICES ARE EXPLICITLY ACQUIRED. * 
023200* * 
023300* EACH OF THE FOUR TARGET PROGRAMS ARE EVOKED TO ESTABLISH * 
023400* TRANSACTIONS WITH THE REMOTE SYSTEMS. * 
023500* * 
023600* THE MAIN INQUIRY MENU (CIMENU) IS WRITTEN TO THE USER'S * 
023700* DISPLAY. * 
023800* * 
023900* EVOKE PROGRAM "CTFMULCL" ON REMOTE SYSTEM IN LIBRARY ICFLIB. * 
024000« * 
O24 1 OD Kx KK AAR KAA KKA KKK KK RK RRR KERR KER ER RRR KER RRR RRR RRR RRR ERE REE ERERER RE 
024200* Ey 


024300 ACQUIRE "ICFOO " FOR CMNFIL. 
024400 ACQUIRE "ICFO1 " FOR CMNFIL. 
024500 ACQUIRE "ICFO2 " FOR CMNFIL. 
024600 ACQUIRE "ICFO3 " FOR CMNFIL. 
024700 PERFORM EVOKE-ROUTINE THRU EVOKE-EXIT. 


024800* 
024900 WRITE DSPREC FORMAT IS "CIMENU" 
025000 INDICATORS ARE DSPF-INDIC-AREA. 


O25 LOD KAR KAA KKK AKKA KKK KEK RK RRR ERE E RRR RRR KERR RE RRR RRR RR RRR REE RERERERER RE 
025200* 
025300* DETERMINE USER'S REQUEST 

025400* 

025500* THIS PORTION OF THE PROGRAM ISSUES A READ TO THE DISPLAY 
025600* DEVICE TO RECEIVE THE USER'S REQUEST. THE TYPE 

025700* OF REQUEST MADE IS BASED ON THE DISPLAY FORMAT CURRENTLY 
025800* ON THE SCREEN. THE RECORD FORMAT NAME IS EXTRACTED FROM 
@25900* THE I/O FEEDBACK AREA OF THE DISPLAY FILE AND USED TO 
026000* DETERMINE WHICH ACTION SHOULD BE TAKEN NEXT. 

026100* 


O26 200K AK KAA KKK A KKK KK KKK KR KERR KER RRR KEKE RRR ERE ER ER RRR ERR ER ER RRR ER EER ER 


+ FF FF F FF HF F 
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02/21/89 
02/21/89 
10/03/90 
02/21/89 
10/14/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/14/87 
10/01/87 
10/15/87 
10/01/87 
10/01/87 
10/03/90 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/03/90 
02/22/89 
10/14/87 
10/14/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/15/87 
10/01/87 
10/01/87 
10/13/87 
10/13/87 
10/01/87 
10/14/87 


216 
217 
218 
219 
220 
221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 


237 
238 
239 
240 
241 


242 


Figure 


026300+ [¥j 10/14/87 
026400 READRQ. 10/01/87 
026500 READ DSPFIL INDICATORS ARE DSPF-INDIC-AREA. 10/08/87 
026600 IF RCD-FMT = "CIMENU" 10/01/87 
026700 PERFORM MENU-ROUTINE THRU MENU-EXIT 10/01/87 
026800 GO TO READRQ. 10/01/87 
026900 IF RCD-FMT = "ITMMNU" 10/01/87 
027000 PERFORM ITMIN-ROUTINE THRU ITMIN-EXIT 10/01/87 
027100 GO TO READRQ. 10/01/87 
027200 IF RCD-FMT = "ITMSC2" 10/01/87 
027300 PERFORM ITMRTN-ROUTINE THRU ITMRTN-EXIT 10/01/87 
027400 GO TO READRQ. 10/01/87 
027500 IF RCD-FMT = "ITMSC3" 10/01/87 
027600 PERFORM ITMRTN-ROUTINE THRU ITMRTN-EXIT 10/01/87 
027700 GO TO READRQ. 10/01/87 
027800 IF RCD-FMT = "DTLMNU" 10/01/87 
027900 PERFORM DTLIN-ROUTINE THRU DTLIN-EXIT 10/01/87 
028000 GO TO READRQ. 10/01/87 
028100 IF RCD-FMT = "DTLSCR" 10/08/87 
028200 PERFORM DTLRTN-ROUTINE THRU DTLRTN-EXIT 10/08/87 
028300 GO TO READRQ. 10/08/87 
028400 WRITE DSPREC FORMAT IS "CIMENU". 10/01/87 
028500 GO TO READRQ. 10/01/87 
028600/ 10/01/87 
O28 7 OD KAR KAA KKK A KKK K KEKE RRR RRR EKER ER EKER RR ER RR ERE RRR KERR ERR ERERERE 10/13/87 
028800* * 10/13/87 
028900* MAIN MENU * 10/13/87 
029000* * 10/13/87 
029100* THE MAIN MENU IS READ TO DETERMINE THE REQUEST ENTERED * 10/13/87 
029200* BY THE USER. IF CMD 1 IS PRESSED, THE PROGRAM IS ENDED. * 10/13/87 
029300* IF OPTION = 1, AN ITEM INQUIRY MENU IS WRITTEN TO * 10/13/87 
029400* THE SCREEN. IF OPTION = 2, A CUSTOMER INQUIRY MENU IS * 10/13/87 
029500* WRITTEN TO THE SCREEN. * 10/13/87 
029600* * 10/13/87 
O29 7 OD KAKA A KKK AK KKK KEKE KEKE KKK ERE RE RE R RRR ER RR ER EK RRR KER ERE REE ERERR RR 10/13/87 
029800* 10/14/87 
029900 MENU-ROUTINE. 10/01/87 
030000 IF CMD-KEY = "01" 10/01/87 
030100 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 10/01/87 
030200 GO TO END-JOB. 10/01/87 
030300 IF OPTION = "1" 10/01/87 
030400 WRITE DSPREC FORMAT IS "ITMMNU" 10/01/87 
030500 ELSE 10/01/87 
030600 WRITE DSPREC FORMAT IS "DTLMNU". 10/01/87 
030700 MENU-EXIT. 10/01/87 
030800 EXIT. 10/01/87 
030900/ 10/01/87 
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243 
244 
245 
246 
247 
248 
249 
250 


251 
253 
255 


257 
258 


259 
260 


261 


262 
263 


Figure 
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O3 LOD & xR AAR KAA KK ARK KKK K RK RRR KER EKER EKER KK RR RR ER EK RRR KER RRR REE ERERR RE 
031100* 

031200* ITEM INQUIRY 
031300* 
031400* THE ITEM NUMBER REQUESTED BY THE USER ON THE ITEM INQUIRY 
031500* SCREEN IS CHECKED. THIS IS DETERMINED BY THE 
031600* DISPLAY RECORD FORMAT BEING PROCESSED - IN THIS CASE ITMMNU. 
031700* 
031800* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. IF CMD KEY 2 
031900* IS PRESSED, THE ITEM INQUIRY REQUEST IS CANCELED, AND THE 
032000* MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 
032100* 
032200* IF AN ITEM NUMBER IS ENTERED, A ITEM INQUIRY REQUEST IS 
032300* SENT TO THE APPROPRIATE REMOTE SYSTEM. THE REMOTE SYSTEM 
032400* IS SELECTED BASED ON THE ITEM NUMBER REQUESTED. 

032500* 
032600* A CHECK IS MADE FOR THREE CONDITIONS FOLLOWING THE READ. 
032700* 1) THE REMOTE SYSTEM TIMED OUT, 2) NO DATA RECEIVED, AND 
032800* 3) DATA RETURNED IN AN UNEXPECTED RECORD FORMAT. 

032900* 
033000* IF THE REMOTE SYSTEM TIMES OUT (MAJ-MIN = 0310) A MESSAGE 
033100* IS WRITTEN TO THE SCREEN, ASKING TO TRY AGAIN OR END THE 
033200* PROGRAM. 

033300* 
033400* IF NO DATA IS RECEIVED AFTER THE READ OPERATION TO THE 
033500* PROGRAM DEVICE (MAJ-MIN = 03 ) THE REQUEST IS SENT AGAIN 
033600* TO THE REMOTE SYSTEM AND THE READ OPERATION IS ISSUED TO 
033700* THE PROGRAM DEVICE. 

033800* 
033900* IF THE RECORD RETURNS WITH THE WRONG RECORD FORMAT, THE 
034000* PROGRAM WILL GO TO EXIT-FORMAT-ERR ROUTINE. 

034100* 


O34 200 4x KAA K KAA KKK EKER RRR RRR KERR ER EK RRR RRR ER EKER RRR ERE REE REE ER ERERR 


034300 Ey 


i i i i eo 


034400 ITMIN-ROUTINE. 
034500 IF CMD-KEY = "Q1" 
034600 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 
034700 GO TO END-JOB. 
034800 IF CMD-KEY = "02" 
034900 WRITE DSPREC FORMAT IS "CIMENU" 
035000 GO TO ITMIN-EXIT. 
035100 MOVE CORR ITMMNU-I TO ITMREQ. 
* ** CORRESPONDING items for statement 250: 
* ae ITEMNO 
* *x End of CORRESPONDING items for statement 250 


035200 IF ITEMNO OF ITMMNU-I LESS THAN 399999 GO TO XICFO1. 
035300 IF ITEMNO OF ITMMNU-I LESS THAN 699999 GO TO XICFO2. 
035400 IF ITEMNO OF ITMMNU-I LESS THAN 899999 GO TO XICFO3. 
035500 XICFO1. 

035600 OVE "ICFO1 " TO PGM-DEV-NME. 

035700 GO TO XITMIN. 

035800 XICFO2. 


035900 OVE "ICFO2 " TO PGM-DEV-NME. 
036000 GO TO XITMIN. 

036100 XICFO3. 

036200 OVE "ICFO3  " TO PGM-DEV-NME. 
036300 XITMIN. 

036400 OVE 150 TO LNGTH OF ITMREQ. 
036500 WRITE CMNREC FORMAT IS "$$SEND" 
036600 TERMINAL IS PGM-DEV-NME. 
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10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
02/21/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/15/87 
10/14/87 
10/14/87 
10/15/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/13/87 
10/14/87 
10/01/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/01/87 
10/01/87 
10/01/87 


10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
02/22/89 
10/01/87 
10/01/87 


264 
265 
266 
267 
268 
270 
272 
273 
274 
276 


277 
278 
279 
280 
281 
282 
283 
284 
285 
286 
287 
288 
289 
290 


036700 RETRY-ITEM. 10/01/87 
036800 READ CMNFIL. 10/08/87 
036900 IF MAJ-MIN = "0310" 10/01/87 
037000 WRITE DSPREC FORMAT IS "TIMOUT" 10/01/87 
037100 READ DSPFIL INDICATORS ARE DSPF-INDIC-AREA 10/08/87 
037200 IF TIMRSP = "1" GO TO RETRY-ITEM END-IF 01/21/88 
037300 IF TIMRSP = "2" GO TO END-JOB END-IF. 01/21/88 
037400 IF MAJ = "03" 10/01/87 
037500 GO TO XITMIN. 10/01/87 
037600 IF RCD-FMT-NME IS NOT EQUAL "ITMRSP" GO TO EXIT-FORMAT-ERR. 10/02/87 
037700 PERFORM ITMOUT-ROUTINE THRU ITMOUT-EXIT. 10/01/87 
037800 ITMIN-EXIT. 10/01/87 
037900 EXIT. 10/01/87 
038000/ 10/14/87 
O38 1 OD kx KKK ARK AA KKK KK KKK RRR ERK ERE E RRR RRR ER RR ER EK RRR RRR ER EKER ER ER ERRRE 10/01/87 
038200* * 10/01/87 
038300* PROCESS ITEM INFORMATION * 10/01/87 
038400* * 10/01/87 
038500* THIS SECTION PROCESSES THE ITEM RECORD RECEIVED FROM THE * 10/01/87 
038600* TARGET PROGRAM AND THE INFORMATION ABOUT THE ITEM IS * 02/21/89 
038700* DISPLAYED. IF ITEMNO IS 0 OR LESS, IT IS AN INVALID REQUEST * 10/15/87 
038800* AND A FRESH ITEM MENU IS WRITTEN TO THE SCREEN. IF THE * 10/15/87 
038900* REQUEST IS VALID, VALUES ARE CALCULATED BASED ON THE * 10/15/87 
039000* INFORMATION RECEIVED. * 10/15/87 
039100* * 10/01/87 
OZ 9200 KAR KAA KKKAKKK KKK KERR ERK KER RRR RRR RR KR RRR ER EK ERE RE RRR ER ER ERE ER EER RE 10/01/87 
039300 EJ 10/14/87 
039400 ITMOUT-ROUTINE. 10/01/87 
039500 IF ITEMNO OF ITMRSP NOT GREATER THAN 0 10/01/87 
039600 WRITE DSPREC FORMAT IS "ITMMNU" 10/01/87 
039700 GO TO ITMOUT-EXIT. 10/01/87 
039800 OVE QTYLST TO QAVAIL OF ITMSC2-0. 10/01/87 
039900 OVE QTYOO TO QTYO OF ITMSC2-0. 10/01/87 
040000 OVE QTYOH TO QTYH OF ITMSC2-0. 10/01/87 
040100 OVE QTYBO TO QTYB OF ITMSC2-0. 10/01/87 
040200 OVE UNITQ TO UNT OF ITMSC2-0. 10/01/87 
040300 OVE PRQ1 TO PR1 OF ITMSC2-0. 10/01/87 
040400 OVE PRQ@5 TO PR5 OF ITMSC2-0. 10/01/87 
040500 OVE UFRT TO UFR OF ITMSC2-0. 10/01/87 
040600 OVE DESC TO DSC OF ITMSC2-0. 10/07/87 
040700 WRITE DSPREC FORMAT IS "ITMSC2". 10/07/87 
040800 ITMOUT-EXIT. 10/01/87 
040900 EXIT. 10/01/87 
041000* 10/14/87 
O41 LOD kx KAA RAAKKA RRR KE RRR RRR ERE RER EKER KK ERE RER EK RRR KERR RRR REE ER ERR 02/21/89 
041200* * 02/21/89 
041300* ADDITIONAL ITEM INFORMATION * 02/21/89 
041400* * 02/21/89 
041500* ADDITIONAL ITEM INFORMATION IS PROCESSED AND THE RESULT * 02/21/89 
041600* DISPLAYED ON THE SCREEN WHEN A RESPONSE IS READ FROM THE * 02/21/89 
041700* DISPLAY STATION WITH AN ITEM SCREEN RECORD FORMAT. * 02/21/89 
041800* * 02/21/89 
041900* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. IF CMD KEY 2 * 02/21/89 
042000* IS PRESSED, THE ITEM INQUIRY IS ENDED, AND THE MAIN MENU * 02/21/89 
042100* (CIMENU) IS WRITTEN TO THE SCREEN. IF CMD KEY 3 IS PRESSED, * 02/21/89 
042200* THE ITEM INQUIRY MENU IS WRITTEN TO THE SCREEN. BY PRESSING * 02/21/89 
042300* ENTER WHEN SCREEN 2 IS DISPLAYED, MORE INFORMATION (PROFIT-  * 02/21/89 
042400* LOSS) WILL BE DISPLAYED TO THE SCREEN. WHEN SCREEN 3 IS * 02/21/89 
042500* DISPLAYED, AN ENTER WILL WILL CAUSE THE ITEM INQUIRY MENU * 02/21/89 
042600* TO BE WRITTEN TO THE SCREEN. * 02/21/89 
042700* * 02/21/89 
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ZEOO KKK KKK KKK KER KA KK RRR RRR RK REE RRR RRR ER ERE RRR ERR KERR ER ER ERE KR ERERERERER 


TINE THRU DETACH-EXIT 


ABO OK RAK KKKKKK ERK AK KKK KERR KER RRR RRR ERR KER RRR RRR ERK KER EKER ER ERE REE ER ERE 


+ + FF 


BAO KAKA KKK AA KKK KKK KKK KERR RRR RRR KERR RRR KERR RR KERR KERR ERR RRR ERK ER ERE RERE REE 


TOO KKK KK KKK KEK ERK K KERR KEK RRR KERR RRR RRR RRR KERR KER RRR RRR KERR KERR RERE REE 


THEN DTOUT-ROUTINE 


IF CMD KEY 2 
IS PRESSED, THE MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 


a i i A A ee 


BZ OQ KAKA KK KKK KKK KEK K KKK ERK ER KR RRR ERR KER RRR RRR ERE KERR ER ER ERE REE ER ERE 


2900% 

3000 ITMRTN-ROUTINE. 

3100 IF CMD-KEY = "01" 

3200 PERFORM DETACH-ROU’ 

3300 GO TO END-JOB. 

3400 IF CMD-KEY = "02" 

3500 WRITE DSPREC FORMAT IS "CIMENU" 

3600 GO TO ITMRTN-EXIT. 

3700 IF CMD-KEY = "03" 

3800 WRITE DSPREC FORMAT IS "ITMMNU" 

3900 GO TO ITMRTN-EXIT. 

4000 IF RCD-FMT = "ITMSC2" 

4100 PERFORM PROFIT-LOSS THRU PROFIT-LOSS-EXIT 
4200 WRITE DSPREC FORMAT IS "ITMSC3" 

4300 GO TO ITMRTN-EXIT. 

4400 WRITE DSPREC FORMAT IS "ITMMNU". 

4500 ITMRTN-EXIT. 

4600 EXIT. 

4700% 

4900% 

5000* THIS SECTION OF THE PROGRAM IS CALLED TO PROCESS 
5100* | THE INFORMATION FOR THE ITEM NUMBER REQUESTED BEFORE 
5200* IT IS SENT BACK TO THE REQUESTING REMOTE SYSTEM. 
5300* 

5500* 

5600* 

5700 PROFIT-LOSS. 

5800 SUBTRACT SLSTM FROM CSTTM GIVING PROFM. 
5900 ULTIPLY PROFM BY 100 GIVING PROFM. 

6000 IF SLSTM GREATER THAN 0 

6100 DIVIDE PROFM BY SLSTM GIVING PROFM. 
6200 ULTIPLY QTYLST BY PRO1 GIVING LOSTS. 
6300 OVE SLSTM TO SLSM. 

6400 OVE SLSTY TO SLSY. 

6500 OVE CSTTM TO CSTM. 

6600 OVE PROFM TO PROFIT. 

6700 OVE CSTTY TO CSTY. 

6800 PROFIT-LOSS-EXIT. 

6900 EXIT. 

7000/ 

7200% 

7300* CUSTOMER INQUIRY 

7400% 

7500* THE REQUEST FROM THE CUSTOMER INQUIRY MENU IS PROCESSED. 
7600* IF CMD KEY 1 IS PRESSED, THE PROGRAM IS ENDED. 
7700% 

7800% 

7900* IF A CUSTOMER NUMBER IS ENTERED, THE CUSTOMER INQUIRY 
8000* REQUEST IS SENT TO THE REMOTE SYSTEM. 

8100* | THRU DTOUT-EXIT ARE PERFORMED. 

8200% 

8400* 

8500 DTLIN-ROUTINE. 

8600 IF CMD-KEY = "01" 

8700 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 
8800 GO TO END-JOB. 

8900 IF CMD-KEY = "02" 

9000 WRITE DSPREC FORMAT IS "CIMENU" 

9100 GO TO DTLIN-EXIT. 

9200 EVDTL. 

9300 MOVE 150 TO LNGTH OF DTLREQ. 

9400 MOVE "ICFQQ =" TO PGM-DEV-NME. 

9500 MOVE CORR DTLMNU-I TO DTLREQ. 


* 
* 
* 


** CORRESPONDING items for statement 326: 


KK 


CUSTNO 


** End of CORRESPONDING items for statement 326 
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02/21/89 
10/14/87 
10/01/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/01/87 
10/01/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
02/21/89 
10/14/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/14/87 
10/13/87 
10/13/87 
10/14/87 
10/01/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/08/87 
10/01/87 
10/01/87 
02/22/89 
10/01/87 
10/01/87 


327 


328 


329 
330 
331 
332 
333 


334 
335 
336 
337 
338 
339 
340 
341 
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049600 WRITE CMNREC FORMAT IS "$$SEND" 
049700 TERMINAL IS PGM-DEV-NME. 

049800 PERFORM DTOUT-ROUTINE THRU DTOUT-EXIT. 
049900 DTLIN-EXIT. 

050000 EXIT. 


050100* 

0502.0 02 aa III I IOI ICI ICI IC ICI ICICI ICI I ICR RII ICI IR AIR AC 
050300* 

050400* PROCESS CUSTOMER INFORMATION 

050500* 


050600* THE CUSTOMER DATA RECEIVED FROM THE TARGET PROGRAM IS 
050700* PROCESSED. IF CUSTOMER NUMBER IS ZERO OR LESS, IT IS AN 
050800* INVALID REQUEST AND THE MAIN MENU IS WRITTEN TO THE SCREEN. 
050900* 

C5 1LOOD Kx x KAA KK KAKA KEK KK RK ERK KER RR ER REK RR E KER RRR RRR ERE RRR ERE KERR RR ERRRE 
051100 Ey 

051200 DTOUT-ROUTINE. 

051300 IF CUSTNO OF DTLRSP NOT GREATER THAN 0 


+ + FF F F FH 


051400 WRITE DSPREC FORMAT IS "CIMENU" 
051500 GO TO DTOUT-EXIT. 
051600 PERFORM CUSTOMER-DETAIL THRU CUSTOMER-DETAIL-EXIT. 


051700 DTOUT-EXIT. 
051800 EXIT. 
051900* 


C5 2OOO KAKA AK KAA KKK KK KEKE KEK ERK K EKER RK ERK ERE ER ER RRR ERE RE RE RREKEREREERRE ER 


052100* * 
052200* THIS SECTION OF THE PROGRAM HANDLES THE REQUEST FOLLOWING * 
052300* THE DISPLAY OF THE CUSTOMER INFORMATION. CMD KEY 1 WILL * 
052400* EXIT THE JOB, CMD KEY 2 WILL DISPLAY THE MAIN MENU, AND * 
052500* AN "ENTER" WILL BRING UP THE CUSTOMER INQUIRY MENU. * 
052600* * 
O52 7 OOD KKK KAA K KK AK KKK KEKE KEKE RRR R EKER EKER KK ER ERE REE RRR ER ERE REE EREER RR 
052800* 

052900 DTLRTN-ROUTINE. 

053000 IF CMD-KEY = "01" 

053100 PERFORM DETACH-ROUTINE THRU DETACH-EXIT 

053200 GO TO END-JOB. 

053300 IF CMD-KEY = "02" 

053400 WRITE DSPREC FORMAT IS "CIMENU" 

053500 GO TO DTLRTN-EXIT. 

053600 WRITE DSPREC FORMAT IS "DTLMNU". 

053700 DTLRTN-EXIT. 


053800 EXIT. 
053900/ 

C5 4OOD Axx K KKK KAA K KARR RK ERR RRR KER RRR RRR RRR KERR RE RE RRKKRER RRR REE RRERR RE 
054100* 

054200* | THE READ OPERATION TO THE PROGRAM DEVICE IS ISSUED. 
054300* A CHECK IS MADE FOR THREE CONDITIONS FOLLOWING THE READ. 
054400* 1) THE REMOTE SYSTEM TIMED OUT, 2) NO DATA RECEIVED, AND 
054500* 3) DATA RETURNED IN AN UNEXPECTED RECORD FORMAT. 

054600« 

054700* IF THE REMOTE SYSTEM TIMES OUT (MAJ-MIN = 0310) A MESSAGE 
054800* IS WRITTEN TO THE SCREEN, ASKING TO TRY AGAIN OR END THE 
054900* — PROGRAM. 

055000* 
055100* IF NO DATA IS RECEIVED AFTER THE READ OPERATION TO THE 
055200* PROGRAM DEVICE (MAJ-MIN = 03 _ ) THE REQUEST IS SENT AGAIN 
055300* TO THE REMOTE SYSTEM AND THE READ OPERATION IS ISSUED TO 
055400* THE ICF PROGRAM DEVICE. 

055500* 
055600* IF THE RECORD RETURNS WITH THE WRONG RECORD FORMAT, THE 
055700* PROGRAM WILL GO TO EXIT-FORMAT-ERR ROUTINE. 

C5 5800 Kae RAK KKK A KKK K KKK RRR RRR ERR E RRR RR RK ERR ER EK RRR ERR ERE ERE ER EER RE 
055900* 

056000* 


* + FF FF FF HF F HF HF HF HF HF KF F 
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056100 CUSTOMER-DETAIL. 


056200 
056300 
056400 
056500 
056600 
056700 
056800 
056900 
057000 
057100 
057200 
057300 
057400 
057500 
057600 
057700 
057800 
057900 
058000 
058100 
058200 
058300 
058400 
058500/ 


READ CMNF 
IF MAJ-MI 


WRITE DSPREC FORMAT IS "TIMOUT" 


IL: 
N = "9310" 


READ DSPFIL INDICATORS ARE DSPF-INDIC-AREA 


IF TIM 
IF TIM 
IF MAJ = 


WRITE CMNREC FORMAT IS "$$SEND" 


RSP 
RSP 
193" 


TERMINAL IS PGM-DEV-NME 


GO T0 


IF RCD-FMT-NME IS NOT EQUAL "DTLRSP" GO TO EXIT-FORMAT-ERR. 
NO OF DTLRSP TO CUSTN OF DTLSCR-O. 

E OF DTLRSP TO CNAME OF DTLSCR-O. 

OR OF DTLRSP TO DLSTR OF DTLSCR-O. 

TM OF DTLRSP TO DSLSM OF DTLSCR-O. 

(01 OF DTLRSP TO DSPM1 OF DTLSCR-O. 

(02 OF DTLRSP TO DSPM2 OF DTLSCR-O. 

(03 OF DTLRSP TO DSPM3 OF DTLSCR-O. 

YD OF DTLRSP TO DSTYD OF DTLSCR-O. 

T OF DTLRSP TO DEPT OF DTLSCR-O. 


MOVE CUST 
MOVE DNAM 
MOVE DLST 
MOVE DSLS 
MOVE DSPM 
MOVE DSPM 
MOVE DSPM 
MOVE DSTT 
MOVE IDEP 


CUSTOMER-DETAIL. 


WRITE DSPREC FORMAT IS "DTLSCR". 


CUSTOMER-DETA 
EXIT. 


IL-EXIT. 


"1" @O TO CUSTOMER-DETAIL END-IF 
"2" GO TO END-JOB END-IF. 


C586 OO KAR KAA KAKA KKK ARK KERR ERK KER RRR RRR RRR ERE EK ERE KER RRR KERR RERERERER RE 


058700« 
058800« 
058900« 
059000« 
059100* 
059200* 
059300« 


THIS SUBROUTINE IS CALLED TO EVOKE THE TARGET PROGRAM. 
THE SAME TARGET PROGRAM (ICFLIB/CTFMULCL) IS EVOKED AT 
FOUR DIFFERENT REMOTE SYSTEMS. 


IDENTIFIES WHICH SESSION SHOULD BE EVOKED. 
DEVICE WAS SPECIFIED IN CMID PRIOR TO CALLING THIS ROUTINE. 


THE PROGRAM DEVICE 


THE PROGRAM 


+ + FF FF 


C5 IA OD Kx x KAA K KKK KKK KEKE KEKE RRR ERE E RRR RRR KERR RE REE RE KR EREREREREREREREER RR 


059500« 
059600« 


16 | 


059700 EVOKE-ROUTINE. 


059800 
059900 
060000 
060100 
060200 
060300 
060400 
060500 
060600 
060700 
060800 
060900 
061000 
061100 
061200 
061300 
061400 
061500* 


OVE " 
WRITE 
TER 
OVE " 
WRITE 
TER 
OVE " 
WRITE 
TER 
OVE " 
WRITE 
TER 
EVOKE-EXIT. 
EXIT. 


ICFOO =" TO PGM-D 


OVE © TO LNGTH OF EVKREQ. 
OVE "CTFMULCL" TO PGMID OF EVKREQ. 
OVE "ICFLIB" TO LIB OF EVKREQ. 


EV- 


ME 


CMNREC FORMAT IS "$$EVOK' 


INAL IS PGM-DEV-N 
ICFO1 " TO PGM-D 
CMNREC FORMAT IS " 

INAL IS PGM-DEV-N 
ICFO2 " TO PGM-D 
CMNREC FORMAT IS " 

INAL IS PGM-DEV-N 
ICFO3 =" TO PGM-D 
CMNREC FORMAT IS " 

INAL IS PGM-DEV-N 


E. 
EV- 


Es 
EV- 


E. 
EV- 


Ey 


ME 


$$EVOK 


ME 


$$EVOK 


ME 


$$EVOK 


I" 


I" 


I" 


I" 


OB LO OD kx KAA K AA KKA KR K ERR RRR KER RRR RRR RRR KER ERE RRR RRR KER RRR REE ER EERE 


061700* 
061800* 
061900* 
062000* 


THE TRANSACTION AND SESSION ARE ENDED FOR EACH OF THE 


REMOTE SY 


STEMS. 


* 
* 
* 
* 


(COVA Chee re ee 
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378 
379 
380 


381 


382 
383 
384 


385 
386 
387 


388 
389 
390 


391 
392 


393 
394 


395 
396 


397 
398 
399 
400 
401 
402 
403 


Figure 


062200* 

062300 ERROR-RECOVERY. 

062400 PERFORM DETACH-ROUTINE THRU DETACH-EXIT. 
062500 CLOSE CMNFIL DSPFIL 

062600 QPRINT. 

062700 MOVE “O" TO ERR-SW. 

062800 ERROR-RECOVERY-EXIT. 

062900 EXIT. 


OBZ 00D Kx KKK AK KAA KKA AKER EKER RRR KERR ER EK ERR RRR EKRRRKERER ER ERE EREERRE 


063100* * 
063200* EXIT-FORMAT-ERR IS BRANCHED TO AFTER A READ TO CMNFIL. THE * 
063300* RCD-FMT-NME RETURNED IN THE I-O-FEEDBACK AREA DOES NOT MATCH * 
063400* THE FORMAT EXPECTED BY THE PROGRAM. AN ERROR MESSAGE IS * 
063500* PRINTED AND THE PROGRAM ENDS. * 
063600* * 
0637 OD KAKA A KKK KKA RRR KER RK RRR ERE RRR REK ERE KER ERE REE RRR RRR ERE ERE ER ERR RE 
063800* 

063900 EXIT-FORMAT-ERR. 

064000 MOVE MAJ-MIN TO RC. 

064100 MOVE "RECORD FORMAT IS INCORRECT ON READ 

064200 TO ERRMSG. 

064300 WRITE PRINTREC. 

064400 CLOSE CMNFIL DSPFIL QPRINT. 

064500 STOP RUN. 

064600« 

064-7 OO x a eH KK KKK KR KK IKK KK I IKK KKK KK KKK KKK III IK IK KKK KK KKK II IIR KE RR IK 
064800« * 
064900* THIS SECTION OF THE PROGRAM IS CALLED TO END * 
065000* | THE TRANSACTION WITH THE REMOTE SYSTEM. * 
065100* * 
OBS 200 KARR AA KKK AK KKK KEKE RRR RK RK ERR E RRR RRR KER RR ERERRRRKERERKRERERRERERERERR RE 
065300* 

065400 DETACH-ROUTINE. 

065500 OVE © TO LNGTH OF ITMREQ. 

065600 OVE "ICFOQ " TO PGM-DEV-NME 

065700 WRITE CMNREC FORMAT IS "$$SENDET" 

065800 TERMINAL IS PGM-DEV-NME. 

065900 OVE "ICFO1  " TO PGM-DEV-NME 

066000 WRITE CMNREC FORMAT IS "$$SENDET" 

066100 TERMINAL IS PGM-DEV-NME. 

066200 OVE "ICFO2  " TO PGM-DEV-NME 

066300 WRITE CMNREC FORMAT IS "$$SENDET" 

066400 TERMINAL IS PGM-DEV-NME. 

066500 OVE "ICFO3 =" TO PGM-DEV-NME 

066600 WRITE CMNREC FORMAT IS "$$SENDET" 

066700 TERMINAL IS PGM-DEV-NME. 

066800 DETACH-EXIT. 

066900 EXIT. 

067000* 

O67 LOD KARA AKA AA KKA KKK EKER RRR ERE ER ER RRR KER RR ERE RRR KER RRR RE RRER ER EER EE 
067200* * 
067300* THIS SECTION OF THE PROGRAM IS CALLED TO RELEASE THE PROGRAM * 
067400* DEVICES, END THE SESSION AND END THE PROGRAM. * 
067500* * 
O67 600 KAKA AK KA ARK ARK KEKE KEKE RRR RRR ER ER RRR KER ERE RRR ERK ER ERE REE EREER ER 
067700* Ey 

067800* 


067900 END-JOB. 
068000 DROP "ICFOO " FROM CMNFIL. 
068100 DROP "ICFO1 " FROM CMNFIL. 
068200 DROP "ICFO2 " FROM CMNFIL. 
068300 DROP "ICFO3  " FROM CMNFIL. 
068400 CLOSE CMNFIL DSPFIL QPRINT. 
068500 STOP RUN. 
068600* 
xx ee * END OF SOURCE ** * * * 
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10-63 


* 71 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 009800 


Message... . : No OUTPUT fields found for format CIMENU. 
* 71 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 009800 

Message... . : No OUTPUT fields found for format DTLMNU. 
* 71 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 009800 

Message . .. . : No OUTPUT fields found for format ITMMNU. 
* 71 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 009800 

Message... . : No OUTPUT fields found for format TIMOUT. 


a ee END OF MESSAGES ** * * * 
Message Summary 
Total Info(0-4) Warning(5-19) Error(20-29) Severe (30-39) Terminal (40-99) 


4 0 4 Q ) 0 
Source records read. .......: £686 
Copy records read... ......: 99 
Copy members processed ......: 1 
Sequence errors. .........: @ 
Highest severity message issued. . : 10 


LBLO901 00 Program CSFMUL created in library ICFLIB. 
ee ee * END OF COMPILATION ** * * & 
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Target Program Multiple-Session Inquiry (Example the file-level INDARA DDS keyword, indicating a 
Il): The following describes the COBOL target program for separate indicator area. 

multiple-session inquiry program example. PFILE 

A database file used to retrieve the record for the 
item requested from the remote system. 


QPRINT 


Program Files: The COBOL multiple-session target 
program uses the following files: 


CFILE . . A printer file used to print error messages resulting 
A ICF file used to send records to and receive | frona communications errors: 
records from the source program. It is done with 
DDS Source: The DDS for the ICF file (CFILE) is illustrated 
in Figure 10-24. 
SOURCE FILE. ...... QICFPUB/ICFLIB 
MEMBER ......... CFILE 
SEQNBR¥ snc teal, eect 2 SP ee ho) aaa Ae Sa he hs 5) ie Roc cDietnach ane oF eetheleg sO cease Hane JO setae e200) 
100 [ERR R KK RARER RK ERR KER RRR RRR ERR KERR RE RRR ERR KER ERE RE REE ER ERE RERE REE 10/14/87 
200 Ax * 10/14/87 
300 Ax ICF FILE * 10/14/87 
400 Ax USED IN TARGET MULTIPLE SESSION PROGRAM * 10/14/87 
500 Ax * 10/14/87 
600 AER RR KK RAE RRR ERR KER RRR RRR ERR KERR RE RRR ERR KER ERE RRR ERR ER ERE REE REE 10/14/87 
700 A INDARA 08/04/87 
800 A 05 RQSWRT 08/04/87 
900 A 10 ALWWRT 08/04/87 
1000 A INDTXT(10 '10 END TRANS.') 08/04/87 
1100 A 15 EOS 08/04/87 
1200 A 20 FAIL 08/06/87 
1300 A INDTXT(20 '20 F ABORT ST') 08/06/87 
1400 A RCVFAIL(25 ‘RECEIVED FAIL') 08/04/87 
1500 A 30 DETACH 08/06/87 
1600 A INDTXT(30 '30>DETACH TGT') 08/06/87 
1700 A RCVDETACH(44 'RECV DETACH') 08/04/87 
1800 A R SNDPART 08/04/87 
1900 A INVITE 08/14/87 
2000 A RECTYP 1 10/01/87 
2100 A ITEMNO 6 10/08/87 
2200 A EDATA 130 08/04/87 
2300 A FILL1 13 10/08/87 
2400 A R RCVPART 08/04/87 
2500 A RECID2 6 10/08/87 
2600 A PARTDS 80 10/08/87 
2700 A FILL4 64 08/04/87 
2800 A R RCVTRND 08/07/87 
2900 A RCVTRNRND(40 ‘END OF TRN') 08/07/87 


**** END OF SOURCE ** * * 
Figure 10-24. DDS Source for ICF File Used in Target Program Multiple Session Inquiry 


The DDS source for the database file (PFILE) is illustrated in 


Figure 10-25. 

SOURCE FILE. ...... QICFPUB/ICFLIB 

MEMBER ......... PFILE 

SEQNBR# ice teat Lise thas 2: sa phass 80 eeten. Ah cache evld Sa thers Ori ahaa date eles aete 9. ceetese O 
100 A LIFO 07/02/87 
200 A R DBREC 05/06/87 
300 A RECCUS 1 10/01/87 
400 A DBSEQ 6 08/18/87 
500 A DBDATA 130 07/02/87 
600 A DBFILL 13 10/01/87 
700 A K DBSEQ 07/04/87 


**x** END OF SOURCE **** 
Figure 10-25. DDS Source for Database File Used in Target Program Multiple Session Inquiry 
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The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/CFILE) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(CFILE) ACQPGMDEV(RQSDEV) TEXT("TARGET ICF 
FILE FOR MULTIPLE SESSION PROGRAM") 


The command needed to define the program device entry is: 
OVRICFDEVE PGMDEV(RQSDEV) RMTLOCNAME (*REQUESTER) 


Program Explanation: The following explains the structure 
of the program examples illustrated in Figure 10-26 on 

page 10-67 and Figure 10-27 on page 10-72. The ICF file 
used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference letters in 
the example below correspond to those in the following 
program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the way the user- 
defined formats and the system-supplied formats are used. 
All output operations to the ICF file in the first example are 
done using the WRITE statement with the record format 
name coded as operand. The output operations to the ICF 
file in the second example using system-supplied formats are 
issued with the name of the system-supplied format coded as 
a literal operand. 


Differences between the first and second example are 
described as notes in each of the following descriptions 
where necessary. 


EF¥ = This section defines the ICF file (CFILE) and the data- 
base file (PFILE) used in the program. 


CFILE is the ICF file used to send records to and 
receive records from the remote system. 


MAU-MIN is the variable name used to check for the 
ICF file return codes. 


CMNF-INDIC-AREA is the indicator area used with the 
ICF file to choose options on DDS keywords and oper- 
ations, and receive response indicators on input oper- 
ations. 


Note: In the program using system-supplied formats, 
the input records for CFILE are explicitly coded in the 
program since CFILE is now treated as a program- 
described file. The system-supplied file, QICDMF, 
could have been used instead of CFILE. Using 
system-supplied files can be done by specifying 
QICDMF in the file specification, or by using an 
OVRICFF command to change the file name from 
CFILE to QICDMF. 


HZ_s This section defines the error handling for the program. 
The routine first checks the major/minor return code to 
determine if the error is recoverable. If return code 
3431 is received, it is saved, and control is passed 
back to the main calling program. Return code 3431 is 
not considered a serious error in this example. The 
program then exits the declaratives. 
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If any other error has occurred, the program prints a 
message saying that the program ended abnormally, 
and then ends. 


This routine opens all the files. 


Because the ICF file was created using the 
ACQPGMDEV parameter, the target session is auto- 
matically acquired when the file is opened. 


This routine reads data from the program device 
(CFILE) through a perform statement until a change 
direction is received. The program then goes to [J to 
read the database file. When change direction is 
received, indicator 40 is set on, as defined by the 
RCVTRNRND DDS keyword in the DDS source file for 
ICF file. 


Note: In the program using system-supplied formats, 
a minor return code of '00' is checked to determine if 
change direction has been received. 


The program uses the requested number received from 
the source program to access the record from the data- 
base. The information retrieved from the database file 
(PFILE) is moved to the work area for the ICF file. A 
write operation is issued to the program device using 
record format SNDPART. The write operation sends 
the requested information back to the source program. 


If the requested number is not found, zero is propa- 
gated into the field. 


If an error occurs on the write operation, control passes 
to @. 

If no error occurs on the write, control goes back to 

GQ. 

Note: In the program using the system-supplied 


format, the WRITE statement uses the $$SEND format 
to send the data. 


A read operation is issued to the program device. 


If a detach indication is received, the program goes to 
El to end the program. When a detach is received, 
indicator 44 is set on, as defined by the RCVDETACH 
keyword in the DDS for the ICF file. 

Note: In the system-supplied format example, the 
read operation is sent without using a record format 
name. Also, a minor return code of '08' is checked for 
the detach received condition. 


This routine is called to issue the read operation to the 
program device until the RCVTRNRND indication is 
received. 


Note: In the system-supplied format example, there is 
no J. Instead, a minor return code of '00' is checked 
for the turnaround indication in J. 


This routine is called to end the program. 
The following message is written to the print file: 
CTDMUL HAS COMPLETED NORMALLY 


The files are closed. The program device is automat- Note: In the program using system-supplied formats, 


ically released as a result of the close operation, and 


the program ends. 


the following message is printed: 
CTFMUL HAS COMPLETED NORMALLY 


Program: “eds, ge tela pe a ae ee BE -CTDMUL 
EADRARYs 3-3 al eke red? Be ee aE ICFLIB 
Source file ............ :  QICFPUB 
Library 0% 2k) ee we ape lar 8 ICFLIB 
Source member ........... 2 CTDMUL 10/03/90 14:30:28 
Generation severity level .....: 29 
Text ‘description’. ........:  CBL Multiple Session Inquiry - Target DDS 
Source listing options ....... : ¥*SQURCE 
Generation options. ........:  *NONE 
Message limit: 
Number of messages ........ :  *NOMAX 
Message limit severity ......: 29 
Print file... ....... 4... : + QSYSPRT 
BUDRANY aie. cx see coy, Gelb Sa: cok eee Ae EE *LIBL 
FIPS flagging .......... =. :  ¥*NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ......... +... =:  *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release... . 2... . ~~ 3) *CURRENT 
User profile. ........... :  *USER 
Authority ............. 3:  *LIBCRTAUT 
Compiler. .......... 4. 2 IBM AS/400 COBOL/400 
1 000100 IDENTIFICATION DIVISION. 10/01/87 
2 000200 PROGRAM-ID. CTDMUL. 10/01/87 
QOO3 OOK xx KAA KKA KKK AKER EKER RRR EKER ERE KERR KER ERE KERR RRR ERE RRR ER RRR RERR RE 10/01/87 
000400* THIS PROGRAM WILL HANDLE THE REQUEST FOR EITHER A CUSTOMER * 10/01/87 
000500* NUMBER OR AN ITEM NUMBER. THIS IS ACCOMPLISHED BY MAKING * 10/01/87 
000600* THE DATABASE FILE STRUCTURE (KEY LENGTH, KEY POSITION, RECORD * 10/01/87 
000700* LENGTH, RECORD SIZE, ETC.) THE SAME FOR BOTH FILES WITH ONLY * 10/01/87 
000800* THE RECORD CONTENTS DIFFERENT. * 10/01/87 
000900* * 10/01/87 
001000* THIS PROGRAM ENDS WHEN A DETACH REQUEST IS RECEIVED FROM * 10/01/87 
001100* THE SOURCE PROGRAM. * 10/01/87 
001200* * 10/01/87 
001300* INDICATORS ASSOCIATED WITH THE ICF FILE I/0 OPERATION * 10/03/90 
001400* ARE DECLARED IN THE WORKING-STORAGE SECTION AND ARE REFERENCED * 10/15/87 
001500* FOR EVERY I/0 OPERATION ISSUED. * 10/15/87 
OO LE OO * xx KAA KK ARK KARR RARER RK ERK RRR E RRR RRR ERR ERE RRR KERR RRR RRR RRR ER ERERE 10/01/87 
3 001700 ENVIRONMENT DIVISION. 10/01/87 
4 001800 CONFIGURATION SECTION. 10/01/87 
5 01900 SOURCE-COMPUTER. IBM-AS400. 01/15/88 
6 002000 OBJECT-COMPUTER. IBM-AS400. 01/15/88 
7 002100 SPECIAL-NAMES. I-0-FEEDBACK IS IO-FBA 10/01/87 
8 002200 OPEN-FEEDBACK IS OPEN-FBA. 10/01/87 
9 002300 INPUT-OUTPUT SECTION. 10/01/87 
002400* Fy 10/01/87 
10 002500 FILE-CONTROL. 10/01/87 
11 002600 SELECT PFILE ASSIGN TO DATABASE-PFILE 10/01/87 
12 002700 ORGANIZATION IS INDEXED 10/01/87 
13 002800 ACCESS IS RANDOM 10/01/87 
14 002900 RECORD KEY IS EXTERNALLY-DESCRIBED-KEY 10/01/87 
15 003000 WITH DUPLICATES. 10/01/87 
16 003100 SELECT CFILE ASSIGN TO WORKSTATION-CFILE-SI 10/01/87 
17. 003200 ORGANIZATION IS TRANSACTION 10/01/87 
18 003300 FILE STATUS IS STATUS-IND MAJ-MIN. 10/01/87 
19 003400 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 10/01/87 
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20 003500 DATA DIVISION. 
21 003600 FILE SECTION. 


22 003700 FD PFILE 

23 003800 LABEL RECORDS ARE STANDARD. 

24 003900 01 PREC. 

25 004000 COPY DDS-ALL-FORMATS OF PFILE. 

26 +000001 05 PFILE-RECORD PIC X(150). 
+000002* 1-0 FORMAT: DBREC FROM FILE PFILE OF LIBRARY ICFLIB 
+000003* 
+000004*THE KEY DEFINITIONS FOR RECORD FORMAT DBREC 
+000005* NUMBER NAME RETRIEVAL TYPE ALTSEQ 
+000006* 0001  DBSEQ ASCENDING AN NO 

27 +000007 05 DBREC REDEFINES PFILE-RECORD. 

28 +000008 06 RECCUS PIC X(1). 

29 +000009 06 DBSEQ PIC X(6). 

30 +000010 06 DBDATA PIC X(130). 

31 +000011 06 DBFILL PIC X(13). 

32 004100 FD CFILE 

33 004200 LABEL RECORDS ARE STANDARD. 

34 004300 01 ICFREC. 

35 004400 COPY DDS-ALL-FORMATS-I-0 OF CFILE. 

36 +000001 05 CFILE-RECORD PIC X(150). 
+000002* INPUT FORMAT: SNDPART FROM FILE CFILE OF LIBRARY ICFLIB 
+000003* 

37 +000004 05 SNDPART-I REDEFINES CFILE-RECORD. 

38 +000005 06 RECTYP PIC X(1). 

39 +000006 06 ITEMNO PIC X(6). 

40 +000007 06 EDATA PIC X(130). 

41 +000008 06 FILL PIC X(13). 
+000009* OUTPUT FORMAT: SNDPART FROM FILE CFILE OF LIBRARY ICFLIB 
+000010* 

42 +000011 05 SNDPART-O REDEFINES CFILE-RECORD. 

43 +000012 06 RECTYP PIC X(1). 

44 +000013 06 ITEMNO PIC X(6). 

45 +000014 06 EDATA PIC X(130) 

46 +000015 06 FILL PIC X(13). 
+000016* INPUT FORMAT:RCVPART FROM FILE CFILE OF LIBRARY ICFLIB 
+000017* 

47 +000018 05 RCVPART-I REDEFINES CFILE-RECORD. 

48 +000019 06 RECID2 PIC X(6). 

49 +000020 06 PARTDS PIC X(80). 

50 +000021 06 FILL4 PIC X(64). 
+000022* OUTPUT FORMAT:RCVPART FROM FILE CFILE OF LIBRARY ICFLIB 
+000023* 

51 +000024 05 RCVPART-0 REDEFINES CFILE-RECORD. 

52 +000025 06 RECID2 PIC X(6). 

53 +000026 06 PARTDS PIC X(80). 

54 +000027 06 FILL4 PIC X(64). 
+000028* INPUT FORMAT: RCVTRND FROM FILE CFILE OF LIBRARY ICFLIB 
+000029% 
+000030* 05 RCVTRND-I REDEFINES CFILE-RECORD. 
+000031* OUTPUT FORMAT:RCVTRND FROM FILE CFILE OF LIBRARY ICFLIB 
+000032* 
+000033* 05 RCVTRND-O REDEFINES CFILE-RECORD. 

55 004500 FD QPRINT 

56 004600 LABEL RECORDS ARE OMITTED. 

57. 004700 01 PRINTREC. 

58 004800 05 RC PIC 9999., 

59 004900 05 ERRMSG PIC X(128). 

60 005000 WORKING-STORAGE SECTION. 

61 005100 77 MAJ-MIN-SAV PIC X(4). 

62 005200 77 STATUS-IND PIC X(2). 

63 005300 77 INDON PIC 1 VALUE B"1". 

64 005400 77 INDOFF PIC 1 VALUE B"0". 

65 005500 77 LEN PIC 9(10)V9(5) COMP 

66 005600 VALUE 0. 

67 005700 77 CMD2 PIC X(31) 


<-AL 
<-AL 


<-ALL 
<-ALL 


<-AL 


<-ALL 
<-ALL 


<-AL 


<-ALL 
<-ALL 
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<-ALL 
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<-ALL 
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<-AL 


<-ALL 
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<-ALL 
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L-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 


-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
-FMTS 
L-FMTS 
-FMTS 
L-FMTS 
L-FMTS 
L-FMTS 
L-FMTS 
L-FMTS 
L-FMTS 


10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 


10/01/87 
10/01/87 
10/01/87 
10/01/87 


68 005800 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 


69 005900 01 CMNF-INDIC-AREA. 
006000* ALLOW WRITE (ALWWRT) INDICATOR 
70 006100 05 IN10 PIC 1 INDIC 10. 
71 006200 88 IN10-ON VALUE B"1". 
72 006300 88 IN10-OFF VALUE B"0". 
006400* RECEIVE TURNAROUND (RCVTRNRND) INDICATOR 
73 006500 05 IN40 PIC 1 INDIC 40. 
74 006600 88 IN40-ON VALUE B"1". 
75 006700 88 IN40-OFF VALUE B"0". 
Q06800* RECEIVE DETACH (RCVDETACH) INDICATOR 
76 006900 05 IN44 PIC 1 INDIC 44. 
77 007000 88 IN44-ON VALUE B"1". 
78 007100 88 IN44-0FF VALUE B"0". 
79 007200 01 MAJ-MIN. 
80 007300 05 MAJ PIC X(2). 
81 007400 05 MIN PIC X(2). 
007500/ 


82 007600 PROCEDURE DIVISION. 
007700 DECLARATIVES. 
007800 ERR-SECTION SECTION. 
COT DOO Xe HH KKK KR KK IK KK III KK KI I IK KK II TOK KK TOK KK II TOK KKK IIR IK IIIA KK 
008000 Eq 
008100* 
008200 USE AFTER STANDARD ERROR PROCEDURE ON CFILE. 
008300 CFILE-EXCEPTION. 
008400« 
008500* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION 
008600* 
008700* MAJOR CODE 34 - INPUT EXCEPTION. 

83 008800 IF MAJ = "34" 
008900* DATA TRUNCATED IN INPUT AREA. 


84 009000 IF MIN = "31" 

85 009100 MOVE MAJ-MIN TO MAJ-MIN-SAV 

86 009200 GO TO EXIT-DECLARATIVES 
009300 ELSE 

87 009400 GO TO EXIT-DECLARATIVES. 
CCC Cn eS Se eS Se SS eS SS 
009600* * 
009700* PRINT A MESSAGE SAYING CTDMUL PROGRAM ENDED ABNORMALLY. * 
009800* CLOSE ALL THE FILES AND END THE PROGRAM. THIS ROUTINE IS CALLED * 
009900* WHEN A NON-RECOVERABLE ERROR OCCURS IN ICF FILE. * 
010000 * 
O1O 1 OQ KK KKK KKK RR KK KKK KAKA KAKI KKK KIKI IK IKI KK IKI KIA KIARA KIRK 
010200 GETFBA. 

88 010300 MOVE MAJ-MIN TO RC. 

89 010400 MOVE "CTDMUL HAS COMPLETED ABNORMALLY" TO ERRMSG. 

90 010500 WRITE PRINTREC. 

91 010600 CLOSE PFILE 
010700 CFILE 
010800 QPRINT. 

92 010900 STOP RUN. 
011000* 
011100 EXIT-DECLARATIVES. 
011200 EXIT. 
011300* 

93 011400 END DECLARATIVES. 
OL 15 OQ x KKK RHA KK AKI R K IK KKK KKK RIK KKK KKK RIKKI KI AKIRA KIKI KIKI KIARA 
011600/ 
011700 START-PROGRAM SECTION. 
011800* 
011900 START-PROGRAM-PARAGRAPH. 
012000* Ey 

94 012100 OPEN OUTPUT QPRINT 
012200 I-O  CFILE 
012300 INPUT PFILE. 
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OO OO OO OO OO OO Oe Oe OO OO SO Se SO Oe OO Se SO Oe SS Oe OS Oe Se Oe OO Oe OO Se OOOO OO Oe ee ea ae ae @ 


oO 


ZA QQ KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KKK IKI IK ERE R 
2500* 

2600* READ THE REQUEST FROM THE SOURCE PROGRAM. INDICATOR 40 
2700* INDICATES RCVTRNRND OCCURRED. INDICATOR 44 INDICATES THAT 
2800* DETACH INDICATOR HAS BEEN RECEIVED FROM THE REMOTE SYSTEM. 
2900* 

3000* THIS PROGRAM CHECKS FOR ERRORS ON EVERY ICF FILE 

3100* FILE OPERATION. A MAJOR CODE GREATER THAN 03 INDICATES 
3200* AN ERROR. 

3300* 

BAQO KR KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERK K KK KKK KKK IK IKARIA KERR 
3500+ EJ 

3600 RECEIVE-DATA. 

3700 PERFORM READ-CFILE THRU READ-CFILE-EXIT. 

3800 IF IN40-ON 


+ Fe FF FF FH F 


3900 GO TO SEND-DATA. 
4000 PERFORM RCVTRNRND THRU RCVTRNRND-EXIT 
4100 UNTIL IN40-ON. 


AZO Q KR KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK EKER KK KKK KIKI KIKI KAIRIE ER 
4300* 
4400* A REQUEST FROM THE SOURCE PROGRAM RESULTS IN READING A SINGLE 
4500* RECORD CONTAINING THE REQUESTED CUSTOMER OR ORDER NUMBER. THE 
4600* RESPONSE WILL BE RETURNED IN A SINGLE RECORD CONTAINING EITHER 
4700* THE ITEM OR CUSTOMER INFORMATION, DEPENDING ON THE DATA BASE 
4800* CONTENT. 
4900* 

5000* THE RESPONSE IS SENT TO THE SOURCE PROGRAM BY WRITING TO THE 
5100* PROGRAM DEVICE FILE USING FORMAT SNDPART. 

5200* 
5300* WHEN THE REQUESTED CUSTOMER OR ITEM NUMBER IS NOT FOUND, 
5400* 000000 IS PROPAGATED TO THE KEY FIELD BEFORE THE RESPONSE 
5500* IS SENT BACK TO THE SOURCE PROGRAM. 

5600* 

BT OQ KA KKK KKK KK KKK KKK KKK KKK KK KKK KERR KKK KKK KKK IK IK KK KKK KKK RARER ERE RRR 
5800* 

5900+ 

6000 SEND-DATA. 

6100 MOVE RECID2 OF RCVPART-I TO DBSEQ. 

6200 READ PFILE INVALID KEY MOVE 0 TO DBSEQ. 

6300 MOVE RECCUS TO RECTYP OF SNDPART-O. 

6400 MOVE ZEROS TO CMNF-INDIC-AREA. 

6500 MOVE DBSEQ TO ITEMNO OF SNDPART-O. 

6600 MOVE DBDATA TO EDATA OF SNDPART-O 

6700 WRITE ICFREC FROM PREC FORMAT IS "SNDPART" 

6800 INDICATORS ARE CMNF-INDIC-AREA. 

6900 GO TO RECEIVE-DATA. 

TO QQ KKK KKK KKK KKK KKK KKK KKK KK EKER KKK KK KKK KKK KKK IKI KKK KIA KKK KARIERRE RRR 
7100* 

7200* THIS ROUTINE ISSUES READ OPERATION TO THE PROGRAM DEVICE. 
7300* DETACH INDICATION IS CHECKED FOR AND IF IT OCCURRED, THE 
7400* PROGRAM IS ENDED (IN44-ON). 

7500* 
TE QQ KKK AKA KKK KK KK KKK KKK KK KKK KEK KKK KKK KKK KKK IK IK IK KKK KKK KEKE ERE RRR 
7700+ 
7800 READ-CFILE. 
7900 MOVE ZEROS TO CMNF-INDIC-AREA. 
8000 READ CFILE FORMAT IS "RCVPART" 
8100 INDICATORS ARE CMNF-INDIC-AREA. 
8200 SET IN40-ON TO TRUE. 

8300 IF IN44-ON 

8400 GO TO END-PROGRAM. 

8500 READ-CFILE-EXIT. 

8600 EXIT. 


+ FF F FF FH FH F HF HF HK 


+ FF OF 


BROOK KKK KK KKK KAKA K KKK KKK KKK KKK KKK KKK KKK KKK KKK EKER KK KKK KKK IKI KIKI KERR 
8900* 

9000* THIS ROUTINE READS THE ICF FILE UNTIL RCVTRNRND OCCURS. 
9100* DETACH INDICATION IS CHECKED FOR AND IF IT OCCURRED, THE 
9200* PROGRAM IS ENDED (IN44-ON). 

9300* 


QA OOK KKK KK KKK KEK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KIKI KIKI 


9500* 


+ FF OF 


ICF Programming V4R1 


113 019600 RCVTRNRND. 


114 019700 MOVE ZEROS TO CMNF-INDIC-AREA. 

115 019800 READ CFILE FORMAT IS "RCVTRND" 
019900 INDICATORS ARE CMNF-INDIC-AREA. 

116 020000 IF IN44-ON 

117 020100 GO TO END-PROGRAM. 
020200 RCVTRNRND-EXIT. 
020300 EXIT. 
020400« 
C205 00 2H HH HK I KK KI IKK KK IIT KK KK IIR KK II TOR RK II TOR IK IITA RK IIR IK III AK KIC 
020600* * 
020700* ROUTINE TO END THE JOB AND CLOSE THE FILES. * 
020800* * 
O20 900% KKK KKK KKH KARR KR KKK KKK KKK KKK KKK KKK KEKE KEKE KKK KKK KKK IKI K IIIA KERR 
021000* 
021100* E 


118 021200 END-PROGRAM. 
119 021300 MOVE MAJ-MIN TO RC. 
120 021400 MOVE "CTDMUL HAS COMPLETED NORMALLY" TO ERRMSG. 
121 021500 WRITE PRINTREC. 
122 021600 CLOSE PFILE 

021700 CFILE 

021800 QPRINT. 
123 021900 STOP RUN. 

eee *e* END OF SOURCE ** * * * 


x 35 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 004400 


Message . . . . : No INPUT fields found for format RCVTRND. 
* 35 MSGID: LBLO600 SEVERITY: 10 SEQNBR: 004400 
Message . . . . : No OUTPUT fields found for format RCVTRND. 


x***e** END OF MESSAGES ** *** 
Message Summary 
Total Info(0-4) Warning (5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
() 


2 0 2 0 0 
Source records read... .....: 219 
Copy records read... ......: 44 
Copy members processed ......: 2 
Sequence errors .....-4+6-5+--3: 98 
Highest severity message issued . . : 10 


LBLO901 00 Program CTDMUL created in library ICFLIB. 
xe ee * END OF COMPILATION * * * * * 
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PROSTAM 4 6. a eves, ha Es % aye 
ETDRAN YS oe Ste ae Ge tee os, ER sae oe 
Source file ..........2.2..32 
BAR? age cey cera ces Gece eViee ey 
Source member .......-4.2-623 
Generation severity level .....: 
Text ‘description’. ........: 
Source listing options .......: 
Generation options .........: 

Message limit: 

Number of messages ........: 

Message limit severity ......: 
Print Pile: ccs ae el ee Ae a a 

LDA VAY? “aes cio sect, So Sek cele AH ass tee 
FIPS flagging 2 6.6 2 6 8 we ee 8 
SAA FITAGGING i053. see fey ee a a ce ee 
Flagging severity .........:2 
Replace program ..........: 
Target release... 1... 2.2.2.0? 
User profile 2s 64 6 Be wee et 
Authority a6 6 a ee ae ewe 8S 
COmpT er: ete. ce a erg a ee ors ee) oe 


1 Q00100 IDENTIFICATION DIVISION. 
2 000200 PROGRAM-ID. 


CTFMUL 
ICFLIB 
QICFPUB 
ICFLIB 
CTFMUL 10/03/90 
29 


14:32:29 


CBL Multiple Session Inquiry - Target $$ 


*SOURCE 
ONE 


* 


*NOMAX 
29 
QSYSPRT 
*LIBL 
*NOFIPS *NOSEG *NODE 
*NOFLAG 


*YES 

*CURRENT 

*USER 

*LIBCRTAUT 

IBM AS/400 COBOL/400 


CTFMUL. 


B *NOOBSOLETE 


OQOO3 OOK xR AAR KAA KKK KK KK EKER RRR RRR EKER RRR KER RR ER ERR RRR RRR ERERR RE 
000400* THIS PROGRAM WILL HANDLE THE REQUEST FOR EITHER A CUSTOMER 
000500* NUMBER OR AN ITEM NUMBER. THIS IS ACCOMPLISH 
000600* THE DATABASE FILE STRUCTURE (KEY LENGTH, KEY POSITION, RECORD 
000700* LENGTH, RECORD SIZE, ETC.) THE SAME FOR BOTH FILES WITH ONLY 

000800* THE RECORD CONTENTS DIFFERENT. 


000900« 


ED BY MAKING 


001000* THIS PROGRAM ENDS WHEN A DETACH REQUEST IS RECEIVED FROM 


001100* THE SOURCE PROGRAM. 
001200* 


001300* THIS PROGRAM USES THE SYSTEM-SUPPLIED FORMAT TO ISSUE THE 1/0 
001400* OPERATION AND THEREFORE, DOES NOT USE THE OPTION INDICATORS 
001500* ASSOCIATED WITH THE KEYWORDS. NOTICE THAT THE ICF FILE 
001600* FILE DECLARATION SELECT STATEMENT REFLECTS THE USE OF A 
001700* SEPARATE INDICATOR AREA FOR INDICATORS. 


QOL ROD kx x KAA KK AAR A RRR K EKER RRR KEK EKER RRR RRR ER RRR ER RR RRERERERERRERERERERERRR 


3 001900 ENVIRONMENT DIVISION. 

4 002000 CONFIGURATION SECTION. 

5 02100 SOURCE-COMPUTER. 

6 002200 OBJECT-COMPUTER. 

7 002300 SPECIAL-NAMES. 

8 002400 

9 002500 INPUT-OUTPUT SECTION. 
002600+ 

10 002700 FILE-CONTROL. 


IBM-AS400. 
IBM-AS400. 
I-0-FEEDBACK IS I0-F 
OPEN-FEEDBACK IS OPE 


11 002800 SELECT PFILE ASSIGN TO DATABASE-PFILE 


12 002900 ORGANIZATION IS INDEXED 

13 003000 ACCESS IS RANDOM 

14 003100 RECORD KEY IS EXTERNALLY-DESCRIBED-KEY 
15 003200 WITH DUPLICATES. 

16 003300 SELECT CFILE ASSIGN TO WORKSTATION-CFILE-SI 
17 003400 ORGANIZATION IS TRANSACTION 

18 003500 FILE STATUS IS STATUS-IND MAJ-MIN. 

19 003600 SELECT QPRINT ASSIGN TO PRINTER-QSYSPRT. 


20 003700 DATA DIVISION. 
21 003800 FILE SECTION. 


22 003900 FD PFILE 

23 004000 LABEL RECORDS ARE STANDARD. 

24 004100 01 PREC. 

25 004200 COPY DDS-ALL-FORMATS OF PFILE. 

26 +000001 @5 PFILE-RECORD PIC X(150). 
+000002* I-0 FORMAT: DBREC FROM FILE PFILE 
+000003* 
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BA 
N-FBA. 


OF LIBRARY ICFLIB 


+ + FF FF F FF F F HF F HF 


<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 


10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/03/90 
10/15/87 
10/15/87 
10/01/87 
10/01/87 
10/01/87 
01/15/88 
01/15/88 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 
10/01/87 


74 


+000004*THE KEY DEFINITIONS FOR RECORD FORMAT DBREC 


+000005* NUMBER NAME RETRIEVAL TYPE — ALTSEQ 
+000006* 0001  DBSEQ ASCENDING AN NO 
+000007 05 DBREC REDEFINES PFILE-RECORD. 
+000008 06 RECCUS PIC X(1). 

+000009 06 DBSEQ PIC X(6). 

+000010 06 DBDATA PIC X(130). 
+000011 06 DBFILL PIC X(13). 

004300 FD CFILE 

004400 LABEL RECORDS ARE STANDARD. 

004500 01 ICFREC. 

004600 05 SNDPART. 

004700 10 LNGTH PIC 9(4). 

004800 10 RECTYP PIC X. 

004900 10 ITEMNO PIC X(6). 

005000 10 EDATA PIC X(130). 
005100 10 FILLI PIC X(13). 
005200 05 RCVPART REDEFINES SNDPART. 

005300 10 RECID2 PIC 9(6). 

005400 10 PARTDS PIC X(80). 
005500 10 FILL4 PIC X(64). 
005600 FD QPRINT 

005700 LABEL RECORDS ARE OMITTED. 

005800 01 PRINTREC. 

005900 05 RC PIC 9999. 

006000 05 ERRMSG PIC X(128). 
006100 WORKING-STORAGE SECTION. 

006200 77 MAJ-MIN-SAV PIC X(4). 

006300 77 STATUS-IND PIC X(2). 

006400 77 INDON PIC 1 VALUE B"1". 
006500 77 INDOFF PIC 1 VALUE B"O". 
006600 77 LEN PIC 9(10)V9(5) COMP 
006700 VALUE 0. 

006800 77 CMD2 PIC X(31) 

006900 VALUE "CPYF HEXDUMP *LIST PRTFMT(*HEX)". 
007000* 

007100 61 CMNF-INDIC-AREA. 

007200* RECEIVE TURNAROUND (RCVTRNRND) INDICATOR 

007300 05 N40 PIC 1 INDIC 40. 
007400 88 IN40-ON VALUE B"1". 
007500 88 IN40-OFF VALUE B"O". 
007600* RECEIVE DETACH (RCVDETACH) INDICATOR 

007700 05 N44 PIC 1 INDIC 44. 
007800 88 IN44-ON VALUE B"1". 
007900 88 IN44-OFF VALUE B"O". 
008000* 

008100 01 MAJ-MIN. 

008200 05 MAd PIC X(2). 

008300 05 MIN PIC X(2). 
008400/ 


008500 PROCEDURE DIVISION. 

008600 DECLARATIVES. 

008700 ERR-SECTION SECTION. 

QOBBOO % x x eK KK KKK KKK KKK K KR KKK KKK KKK KKK KKK KKK KEKE KKK KK KK KKK KKK IK IK IKI R 
008900 E 

009000 

009100 USE AFTER STANDARD ERROR PROCEDURE ON CFILE. 

009200 CFILE-EXCEPTION. 
009300* 

009400* CHECK THE MAJOR/MINOR CODES AND TAKE APPROPRIATE ACTION 
009500* MAJOR CODE 34 - INPUT EXCEPTION. 

009600* 

009700 IF MAJ = "34" 
009800* DATA TRUNCATED IN INPUT AREA. 


009900 IF MIN = "31" 

010000 MOVE MAJ-MIN TO MAJ-MIN-SAV 
010100 GO TO EXIT-DECLARATIVES 
010200 ELSE 

010300 GO TO EXIT-DECLARATIVES. 
010400« 


<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 
<-ALL-FMTS 


Figure 10-27 (Part 2 of 4). Target Program Example — CTFMUL (System-Supplied Formats) 
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10/10/87 
0/10/87 
0/10/87 
0/08/87 
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80 


81 


82 
83 
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DO 6D Oe 6 Oe Oe Oe OO Oe Oe Os OO OS oO OO OO OO On OS O_O Os OO aS Ss OS ss a es ss SS 


fa) 


QB OO % eK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KIKI KI IR ERE 
0600* * 
0700* PRINT A MESSAGE SAYING CTDMUL PROGRAM ENDED ABNORMALLY. 

0800* CLOSE ALL THE FILES AND END THE PROGRAM. THIS ROUTINE IS CALLED 
0900* WHEN A NON-RECOVERABLE ERROR OCCURS IN THE ICF FILE. 

1000* 

LLOQ ke KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KEKE KERR KKK KKK KKK KKK K IKEA ERR 
1200* 

1300 GETFBA. 

1400 MOVE MAJ-MIN TO RC. 


+ FF 


1500 MOVE "CTFMUL HAS COMPLETED ABNORMALLY" TO ERRMSG. 
1600 WRITE PRINTREC. 
1700 CLOSE PFILE 
1800 CFILE 
1900 QPRINT. 
2000 STOP RUN. 

2100* 

2200 EXIT-DECLARATIVES. 
2300 EXIT. 

2400* 

2500 END DECLARATIVES. 


ZO QO KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KEK EK KKK KKK KK IK IKI I KIRKE R 
2700/ 

2800 START-PROGRAM SECTION. 

2900 START-PROGRAM-PARAGRAPH. 


3000+ Ey 

3100 OPEN OUTPUT QPRINT 
3200 1-0 CFILE 
3300 INPUT PFILE. 


RCO ne rd 
3500* * 
3600* READ THE REQUEST FROM THE SOURCE PROGRAM. MINOR RETURN CODE '00'* 


3700* INDICATES RCVTRNRND OCCURRED. MINOR RETURN CODE OF '08' * 
3800* INDICATES DETACH HAS BEEN RECEIVED. * 
3900* * 
4000* THIS PROGRAM CHECKS FOR ERRORS ON EVERY ICF FILE 1/0 * 
4100* OPERATION. A MAJOR CODE GREATER THAN 03 INDICATES AN ERROR. * 
4200* * 
D3 OOK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI K IKARIA ERR 
4400« 

4500 RECEIVE-DATA. 

4600 MOVE SPACES TO MAJ-MIN. 

4700 PERFORM READ-CFILE THRU READ-CFILE-EXIT UNTIL 


4800 MIN IS EQUAL TO "00", 
AQ QQ KR KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI K IK IK IIR ERE 
5000* 

5100* A REQUEST FROM THE SOURCE PROGRAM RESULTS IN READING A SINGLE 
5200* RECORD CONTAINING THE REQUESTED CUSTOMER OR ORDER NUMBER. THE 
5300* RESPONSE WILL BE RETURNED IN A SINGLE RECORD CONTAINING EITHER 
5400* THE ITEM OR CUSTOMER INFORMATION, DEPENDING ON THE DATABASE 
5500* CONTENT. 
5600* 

5700* THE RESPONSE IS SENT TO THE SOURCE PROGRAM BY WRITING TO THE 
5800* PROGRAM DEVICE FILE USING FORMAT SNDPART. 

5900* 
6000* WHEN THE REQUESTED CUSTOMER OR ITEM NUMBER IS NOT FOUND, 
6100* 600000 IS PROPAGATED TO THE KEY FIELD BEFORE THE RESPONSE 
6200* IS SENT BACK TO THE SOURCE PROGRAM. 

6300* 

G4 OQ KKK AK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IK IK IK KKK KKK KER EKER ERE RRR 
6500* 

6600 fy 

6700 SEND-DATA. 

6800 MOVE RECID2 OF RCVPART TO DBSEQ. 

6900 READ PFILE INVALID KEY MOVE 000000 TO DBSEQ. 

7000 MOVE RECCUS TO RECTYP. 

7100 MOVE 150 TO LNGTH OF SNDPART. 

7200 MOVE DBSEQ TO ITEMNO OF SNDPART. 

7300 MOVE DBDATA TO EDATA OF SNDPART. 

7400 WRITE ICFREC FORMAT IS "$$SEND". 

7500 GO TO RECEIVE-DATA. 


+ FF F FF FH F KH FH HF HF 
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1 7 BOQ 2 4 RK KK KAKI KKK IKK KK IKK KK III KK III IK KK II TK KIKI IK IK III KKK 10/01/87 
017700* * 02/21/89 
017800* THIS ROUTINE ISSUES THE READ OPERATION TO THE PROGRAM DEVICE * 02/21/89 
017900* UNTIL RCVTRNRND OCCURS. * 02/21/89 
018000* DETACH INDICATION IS CHECKED FOR AND IF IT OCCURRED, THE * 0/01/87 
018100* PROGRAM IS ENDED (RC=_ 08). * 0/01/87 
018200 * 02/21/89 
OQ 18300 2 a HH KKK RK KK KK III KK II IK KK II TKK KIT TOK KK II TK KK IK IKI IK KK 0/15/87 
018400 0/01/87 
018500 READ-CFILE. 0/01/87 
93 018600 READ CFILE 10/01/87 
018700 INDICATORS ARE CMNF-INDIC-AREA. 0/01/87 
94 018800 IF MIN = "Q8" 0/01/87 
95 018900 GO TO END-PROGRAM. 0/01/87 
019000 READ-CFILE-EXIT. 10/01/87 
019100 EXIT. 02/28/89 
019200* 10/01/87 
O19 300 4 eH a HH KKK KR KI IK KK II IKK I IIR IK IIT KKK I IK KK IIT KK KI IK IK IKI KKK 0/01/87 
019400 * 02/21/89 
019500* ROUTINE TO END THE JOB AND CLOSE THE FILES. * 02/21/89 
019600 * 02/21/89 
197 OO x KKK KR KKK KK III KK IKI IK IK II TKK KI TOK IK IIT KK KTR IK II IK KK 0/01/87 
019800 10/01/87 
019900 (H) 0/14/87 
96 020000 END-PROGRAM. 10/01/87 
97 020100 MOVE MAJ-MIN TO RC. 01/14/88 
98 020200 MOVE "CTFMUL HAS COMPLETED NORMALLY" TO ERRMSG. 01/14/88 
99 020300 WRITE PRINTREC. 0/01/87 
100 020400 CLOSE PFILE 0/01/87 
020500 CFILE 0/01/87 
020600 QPRINT. 10/01/87 
101 020700 STOP RUN. 0/01/87 


kee ee END OF SOURCE ** & * 


x***e*e* END OF MESSAGES ** *** 
Message Summary 
Total Info(0-4) Warning (5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
) 


) 0 0 0 0 
Source records read... .....: 207 
Copy records read... ......: «Il 
Copy members processed ......: 1 
Sequence errors... ..-6+6-5+2663 98 
Highest severity message issued. .: 0Q 


LBLO901 00 Program CTFMUL created in library ICFLIB. 
xe ee * END OF COMPILATION * * * * * 


Figure 10-27 (Part 4 of 4). Target Program Example — CTFMUL (System-Supplied Formats) 
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Chapter 11. RPG/400 Communications Applications 


Previous chapters in this book describe the functions pro- 
vided by ICF. This chapter introduces you to the RPG/400 
interface for ICF and provides program examples. 


Two program examples are presented in this chapter. For 
each example, both the source and target programs are pro- 
vided. Each program is written first with user-defined formats 
(data description specifications or DDS) and then with 
system-supplied formats. 


The first example is a batch data transfer application using a 
single session. The second example is a multiple-session 
inquiry application using one display file and four ICF ses- 
sions. 


Not all programming considerations or techniques are illus- 
trated in each example in this chapter. Review these exam- 
ples and the examples provided in the appropriate 
programming book before beginning application design and 
coding. 


Note: The examples in this chapter were written to the 
APPC communications type. Minor changes might be 
required if another communications type is used. 


Introduction to the RPG/400 Interface 


Before you write an RPG/400 communications application, 

you must understand the high-level language interface pro- 
vided by RPG/400 ICF files are defined as WORKSTN files 
in RPG/400. 


The operations you use in the communications portion of 
your program are similar to work station operations. In the 
noncommunications portion of your program, you can use all 
noncommunications operations you normally use to process 
data that is sent or received between your program and the 
remote program. 


Figure 11-1 briefly introduces the RPG/400 statements you 
use in the communications portion of your program. 


Figure 11-1. RPG/400 Statements 


RPG/400 

ICF Operation 

Operation Code Function 

Open OPEN Opens the ICF file 

Acquire ACQ Acquires a program device to 
establish a session 

Get-attributes POST1 Gets the status information of a 
program device 

Read READ2 Receives data from a specific 
program device 

Read-from- READ2 Receives data from any invited 

invited-program- program device? 

devices 


© Copyright IBM Corp. 1997 


Figure 11-1. RPG/400 Statements 


RPG/400 

ICF Operation 

Operation Code Function 

Write WRITE Performs many of the ICF com- 
munications functions in a 
session 

Write/Read EXFMT Performs the specified function 
and then receives data from the 
remote system 

Release REL Releases the program device to 
end the session 

Close CLOSE Closes the ICF file 


1 The POST operation can retrieve either input/output (I/O) feed- 
back information or the get-attributes. The information you get 
depends on the factors specified with the POST. 


2 An RPG/400 read operation can be directed either to a specific 
program device or to all invited program devices. The support 
provided by the RPG/400 compiler determines whether to issue 
an ICF read or read-from-invited-program-devices operation 
based on the format of the read operation. For example, if a 
read is sent with a specific format or terminal specified, the read 
operation is interpreted as an ICF READ operation. Refer to the 
RPG/400 language book for more information. 


3 The read-from-invited-program-devices operation could complete 
without data if the timer interval established with either the timer 
function or wait record (WAITRCD) ends, or your job is ended 
(controlled). 


Refer to the appropriate RPG/400 book for details on the 
syntax and function of each operation. 


Error Handling: The INFDS option of the RPG/400 file 
specification allows you to obtain specific exception or error 
information for a file by defining and naming a data structure 
to contain error information, such as the ICF major and minor 
return codes. 


You must understand the relationship between RPG 
*STATUS values and ICF major/minor return codes. 


Figure 11-2 shows the *STATUS values as returned in the 
RPG/400 INFDS for each major and minor return code. Use 
this list to determine the ICF return code or group of codes 
that corresponds to the *STATUS value. 


Figure 11-2 (Page 1 of 2). *STATUS Values for Major and Minor 
Return Codes 


Major Code Minor Code *STATUS Value 
00 All 00000 
02 All 00000 
03 All (except 09 and 10) 00000 
03 09 01282 
03 10 01331 
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Figure 11-2 (Page 2 of 2). *STATUS Values for Major and Minor 
Return Codes 


Major Code Minor Code *STATUS Value 
04 All 01299 
08 00 01285 
11 00 00011 
34 All 01201 
80, 81 All 01251 
82, 83 All 01255 


Note: The mapping in Figure 11-2 on page 11-1 applies to 
major/minor codes set as a result of acquire, release, and 
general I/O operations. Certain major/minor codes are set 
for open and close errors as well as for other I/O errors. In 
cases where a major/minor code is set as a result of an open 
or close error, the return code will map to either the 01205, 
01216, or 01217 *STATUS value, depending on which is 
applicable. 


The return code field will not be updated for a *STATUS 
value of 01285, 01261, or 01281 when an I/O operation was 
attempted to an unacquired program device, because 
RPG/400 detects these conditions before calling ICF data 
management. This mapping is shown in order to note the 
appropriate RPG/400 *STATUS value to check for the given 
error condition. 


Accessing the Feedback Areas: Use the RPG/400 
POST operation to obtain the open or I/O feedback areas for 
an ICF file. For the RPG/400 support to access information 
from the I/O feedback area, add the following RPG/400 offset 
values to the offset values listed in Appendix C. 


Local AS/400 System 


81 Open Feedback Area 
241 Common I/O Feedback Area 


367 File Dependent Feedback Area 


Example Programs 


The programs presented in this section are: 
e Example | (Batch Data Transfer) 


Figure 11-3 shows a batch data transfer program that 
reads a database file and sends the data to a remote 
system. When the source program finishes sending its 
records, it sends an indication that it is done sending 
records to the target program. The target program then 
starts sending its records until it reaches the end-of-file. 
At end-of-file, the target program sends a detach indi- 
cation to the source program. The two programs end 
their sessions. 


e¢ Example Il (Multiple-Session Inquiry) 


Figure 11-4 on page 11-3 shows an inquiry program 
that accepts inquiries from a display device, sends the 
request to one of four remote AS/400 systems, and 
waits for a response to the inquiry. Based on the input 
received from the display device, the program deter- 
mines the target program to which it sends the inquiry 
request. The same program resides in each of the 
remote systems. 


Figure 11-4 on page 11-3 contains a display device and 
four ICF communications program devices. 


Remote AS/400 System 


Database Program ICF 


File File 


ICF Program Database 


File File 


Figure 11-3. Batch Data Transfer 


11-2 ICE Programming V4R1 
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Display 
Station 


Remote AS/400 System 


ICF Program Database 
File File 
Display File 
Remote AS/400 System 
Program ICF Program Database 
l“ i File File 
ICF File 
Local AS/400 System Remote AS/400 System 
L ICF Program Database 
File File 
Remote AS/400 System 
ICF Program Database 
| | File File 


Figure 11-4. Multiple-Session Inquiry 


The remainder of this chapter discusses the details of the 
two application examples. The DDS source for the ICF file, 
program listings, and an explanation of the programs are 
included. 


Batch Data Transfer (Example 1) 


The following figures show a batch data transfer program. A 
source AS/400 system program communicates with a target 
program on another AS/400 program using the ICF support. 
The source program starts a target program on a remote 
AS/400 system, and transfers a file to that target program. 


The target program responds, after receiving an indication 
that the source is done sending, by reading its own file and 


RSLS198-4 


then sends the records to the source program until it reaches 
end-of-file. At end-of-file, the target program sends a detach 
request to the source program and ends its session. 


Both the source program and the target program are 
described. 


Transaction Flow of the Batch Data Transfer 
(Example I): In Figure 11-5, the source program issues 
an evoke to start a program at the remote AS/400 system. 


Note: An acquire operation is not necessary since the 
device was acquired during the open operation. The device 
was acquired during the open operation because the 
ACQPGMDEV parameter was used when the ICF file was 
created. 
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Local AS/400 System 


Remote AS/400 System 


Database 
File 


Program 


Write 
| 


ICF 
File 


Evoke | ICF 


File 


Program 


as shown in Figure 11-6. 


RSLS146-4 
Figure 11-5. Evoke Request Starts a Target Program 
After issuing the evoke request, the source program sends a 
database file to the target program, which prints the records 
Local AS/400 System Remote AS/400 System 
Read Write Read Write 
Sr >| ial >| >| 
Database | Read | Program|Write ICF ICF Read | Program|Write Printer 
[>| -—————> -————> -————> | 
File File File File 
Read Write Read Write 
|_———>| >| >) -——> |——_—_>| 


Figure 11-6. Target Program Prints Records 


After the target program receives and prints the file, a data- 


base file is sent to the source program. The source program 


AS/400 System 
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prints the records as they are received as shown in 


Figure 11-7. 


Remote AS/400 System 


Printer 


File 


Write 
| | 
Write 
b¢—————| 


Write 
jgvVrite | 


Read 


Program| Read 


Read 


ICF 


File 


Read 
— 
Program Read 

<——_ 


Read 
en 


Database 


File 


Figure 11-7. Source Program Prints the Received Records 


Once all the records have been sent by the target program, 


the target program issues a detach to the source program to 
end the transaction, as shown in Figure 11-8 on page 11-5. 
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Local AS/400 System 


Remote AS/400 System 


Printer Program |Read|_ ICF Detach ICF Write} Program Database 
File File File File 
RSLS149-4 
Figure 11-8. Target Program Ends the Transaction 
DE I IIR I TORR ITO IRR TIT IKI III III IASI III AISI IIIA ISIS II IIIS A. 
Source Program Batch Transfer (Example I): The Ax ICF RECORD FORMATS * 
program. RCVFLD 80A 
R SNDDATA 
3 SNDFLD 80A 
Program Files: The RPG/400 batch data transfer source R EVOKPGM 
program uses the following files: jae ear eae a cern 
3 'USERID') 
SRCICF A PGMID 10A P 
An ICF file used to send records to and receive eae TONE 
records from the target program. A R INVITE 
A 45 INVITE 


DBFILE 
A database file that contains the records to be sent 
to the target program. 


QPRINT 
A printer file that is used to print the records 
received from the target program. 


DDS Source: The DDS used in the ICF file is illustrated 
below. The other files (DBFILE and QPRINT) are program- 
described and therefore do not require DDS. 


[REAR E IOC SI ICES SIG IIIS IOS TOOT TOI ICAI TOI TOI I III III 


Ax * 
Ax ICF FILE * 
Ax USED IN BATCH DATA TRANSFER PROGRAM * 
Ax * 


DR KKK KKK I KIKI KAKI KKK IK KK IKK KI KKK IKK IKK KIKI KKK IK KK IKKE IKKE AIK. 
Ax 
Ax 
Ax 


FILE LEVEL INDICATORS: 


A NDARA 

Ax 

A RCVTRNRND(15 'END OF DATA') 
Ax 

A 30 DETACH 

Ax 

A NDTXT(30 '30->DETACH TARG- 
A ET PROGRAM. ') 

Ax 

A RCVDETACH(35 ‘RECEIVED - 
A DETACHED. ') 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/SRCICF) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(SRCICF) ACQPGMDEV(PGMDEVA) TEXT('ICF FILE 
FOR BATCH DATA TRANSFER’) 


The command needed to define the program device entry is: 


ADDICFDEVE FILE(ICFLIB/SRCICF) PGMDEV(PGMDEVA) 
RMTLOCNAME (CHICAGO) 


Program Explanation: The following describes the struc- 
ture of the program examples illustrated in Figure 11-9 on 
page 11-7 and Figure 11-10 on page 11-12. The ICF file 
used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference numbers 
in the explanation below correspond to those in the following 
program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the use of user- 
defined formats and system-supplied formats. All output 
operations to the ICF file in the first example are done using 
the WRITE statement. All output operations to the ICF file in 
the second example using system-supplied formats are done 
using the EXCPT statement. 


Differences between the first and second example are 
described in notes in each of the descriptions. 


The files used in this program are defined in the file 
specifications section. SRCICF is the ICF file used to 


send records to the target program. 


The files used in the program are opened at the begin- 
ning of the RPG/400 cycle and the ICF program device 
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is implicitly acquired because the ACQPGMDEV 
parameter was specified on the create ICF file 
(CRTICFF) command. 


Note: The input records for SRCICF are explicitly 
coded in the program using system-supplied formats, 
because SRCICF is now treated as a program- 
described file. The system-supplied file QICDMF can 
be used instead of SRCICF. You can use the system- 
supplied file by specifying QICDMF in the file specifica- 
tion, or by using an OVRICFF command to change the 
file name from SRCICF to QICDMF. The OVRICFF 
command can also be used to change the 
ACQPGMDEV parameter of the file. 


FEEDBK is the name of the file information data struc- 
ture (INFDS) used with SRCICF. It contains the fol- 
lowing information: 


¢ Record format name (FMTNM) 

e¢ Program device name (PGMDEV) 

¢ Major/minor return code (MAJMIN, MAJCOD, 
MINCOD) 


This section builds and sends the evoke request to the 
remote system. Because the DDS for the record 
format only specifies the field identifiers with the 

record, the program moves the literal value RTDBATCL 
to the field PGMID, and ICFLIB to the field L/B. Indi- 
cator 50 is set to indicate that the program start 
request is to be sent. 


When the program start request is received at the 
remote system, ICFLIB is searched for RTDBATCL and 
that program is then started. RTDBATCL is a control 
language (CL) program that contains the following: 


ADDLIBLE ICFLIB 
CALL ICFLIB/RTDBAT 


Note: In the program using system-supplied formats, 

the library and program (ICFLIB/RTFBATCL) are speci- 
fied as part of the $$EVOKNI format. RTFBATCL is a 
CL program that contains the following: 


ADDLIBLE ICFLIB 
CALL ICFLIB/RTFBAT 


This section reads a record from the database file. If 
the record read is the end-of-file, the program sets indi- 
cator 98 on and then goes to —Rq. 


If it is not the last record, the data is moved to field 
SNDFLD and the program goes to [QJ to write the 
record to the ICF program device. When control 

returns from [QJ , the next database record is read. 
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Data is read from the program device associated with 
the ICF file (SRCICF). 


If an error occurs on the read (return code greater than 
03), the error is handled. Otherwise, if data is received 
(return code not = 03), the data is written to the printer 
file (QPRINT). 


This section reads data records until the detach indi- 
cation is received from the target program. When the 
detach is received, indicator 35 is set on, as defined by 
the RCVDETACH keyword in the DDS for the ICF file. 
Note that RCVDETACH is a file level-keyword. 


Note: In the program using system-supplied formats, 
the minor return code of ‘08’ is checked to verify 
whether the detach is received. 


After the detach request has been received, the fol- 
lowing message is written to the printer file: 


RSDBAT HAS COMPLETED NORMALLY 
The session is ended in [J. 


Note: The program name is RSFBAT in the program 
using system-supplied formats. 


When an I/O operation to the ICF file (SRCICF) com- 
pletes unsuccessfully, the following message is written 
to the printer file: 


RSDBAT HAS COMPLETED ABNORMALLY 
The session is ended in Jj. 


Note: The program name is RSFBAT in the program 
using system-supplied formats. 


The program ends the job by setting on last run (LR) 
indicator and returning to caller of the program. The 
ICF file is closed, and the session ends at the end of 
the RPG/400 cycle. 


This subroutine is called to write data to the program 
device associated with the ICF file using the format 
SNDDATA. If an error occurs, the program goes to 
El and a message is printed. 


Note: The $$SENDNI format is used instead of the 
user-defined SNDDATA format in the program using 
system-supplied formats. 


This subroutine is called to perform an invite request to 
the ICF program device using format INVITE. If an 
error occurs, the program goes to [J and a message 
is printed. 


Note: The $$SEND format is used instead of the 
user-defined INVITE format in the program using 
system-supplied formats. 


Compiler. ........... =. : IBM AS/400 RPG/400 
Command Options: 
Programs, 2° 5.030% se? Sel Se at oid ak ee HS ICFLIB/RSDBAT 
Source file ..........3 ICFLIB/QICFPUB 
Source member ......... :  *PGM 
Text not available for message RXT0073 file QRPGMSG. 
Generation options. ...... 3:  ¥*NOLIST *NOXREF *NOATR 
Source listing indentation... :  ¥*NONE 
SAA flagging... ....... 2 *NOFLAG 
Generation severity level ...: 9 
Print. file. 4.4 «ede aw Y  *LEBL/QSYSPRT 
Replace program ........: = *YES 
Target release... ...... :  *CURRENT 
USer (protien: ew we kom a MUSSER, 
AUTHORITY: wvacce: 4 i wear ae se va i *LIBCRTAUT 
TOXb a) oe ee we ce eee we ee ASRCMBRTXT. 
Phase trace ..........:  ¥NO 
Intermediate text dump... .. :  *NONE 
Snap: dump 2 ena a Par ed A est *NONE 
Codelist............: = *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member. ......... +... :  RSDBAT 
FAG: iia ce, ck Lise lg Vee Ble tee ee 8 GQTCEPUB 
ETDPA LY! caro ods so, 4e: Woes ahetoo ses cer as ICFLIB 
Last Change ..........: 03/20/89 15:26:21 
DESCHIPtHONes 3h a! whee tar He hee rpg batch file transfer using dds source 


Source Listing 


100 H&K AKA K KAA KKK KKK KKK ERK KKK KKK KKK ERK KERR ERE KEK ERK ERK RE REKERRERREREER 
200 Hx 
300 H* THIS IS A BATCH FILE TRANSFER PROGRAM THAT READS A SEQUENTIAL 
400 H* FILE AND SENDS THE RECORDS TO THE REMOTE SYSTEM UNTIL THE END 
500 H* OF FILE IS REACHED. AT THIS TIME, THE PROGRAM STOPS SENDING 
600 H* AND STARTS RECEIVING RECORDS FROM THE REMOTE SYSTEM UNTIL A 
700 H* DETACH INDICATION IS RECEIVED. 
800 H* 
900 H&K AKA K KKK KKK KERR KK EK KK KKK KKK KERR KEK ERE KKK ERK EERE EKER ERR RRR ER 
1000 « 

H 
1100 FSRCICF CF E WORKSTN 
1200 F KINFDS FEEDBK 


RECORD FORMAT(S): LIBRARY ICFLIB FILE SRCICF. 
EXTERNAL FORMAT RCVDATA RPG NAME RCVDATA 
EXTERNAL FORMAT SNDDATA RPG NAME SNDDATA 
EXTERNAL FORMAT EVOKPGM RPG NAME EVOKPGM 
EXTERNAL FORMAT ENDREC RPG NAME ENDREC 
EXTERNAL FORMAT INVITE RPG NAME INVITE 


1300 FDBFILE IF F 80 DISK 

1400 FQPRINT O F 132 PRINTER 

1500 IDBFILE NS 80 

1600 I 1 80 DBDATA 


*NODUMP 


*NOOPTIMIZE 


KKK 


10/14/87 
10/14/87 
10/14/87 
10/14/87 
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1700 
A000000 
A000001 
BO00000 
B000001 
C000000 
DeG0000 
E000000 

1800 

1900 

2000 

2100 

2200 

2300 

2400 
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Ix @ 

INPUT FIELDS FOR RECORD RCVDATA FILE SRCICF FORMAT RCVDATA. 
1 80 RCVFLD 

INPUT FIELDS FOR RECORD SNDDATA FILE SRCICF FORMAT SNDDATA. 
1 80 SNDFLD 

INPUT FIELDS FOR RECORD EVOKPGM FILE SRCICF FORMAT EVOKPGM. 

INPUT FIELDS FOR RECORD ENDREC FILE SRCICF FORMAT ENDREC. 

INPUT FIELDS FOR RECORD INVITE FILE SRCICF FORMAT INVITE. 

IFEEDBK DS 


I 38 45 FMTNM 

I 273 282 PGMDEV 

I 401 404 MAJMIN 

I 401 402 MAJCOD 

I 403 404 MINCOD 

CHR KRHA KA KR KK KK ERIK IKK KAKA KR EK IER IR IKI KAKA K ERE KEKE RIK IKI IK IKIERIER EK 
Cx 


Cx EVOKE PROGRAM 'RTDBATCL' ON REMOTE SYSTEM IN LIBRARY ICFLIB. 
C* INDICATOR 50 (*IN50) IS ASSOCIATED WITH THE EVOKE KEYWORD. 
Cx 


CRRA KKK KKK KKK KKK KKK KK KKK EKER KKK KK KKK KK KK IK KKK IKI KKK ERE KEKE KEKE K RR 


c« 

c ITMIN TAG 

C MOVEL'RTDBATCL' PGMID 

c MOVEL'ICFLIB 'LIB 

c MOVE '1' *IN50 

c WRITEEVOKPGM ISSUE EVOKE 
C MOVE '@! *IN50 

c MAJCOD —-CABGT'@3! NOTOKR ERROR? 


CRRA RK KKK KKK KKK KKK KKK RK KKK KKK KKK KKK KKK KKK KIKI KIKI RRR KARI 


Cx AFTER SUCCESSFUL EXECUTION OF THE EVOKE OPERATION, A RECORD 
Cx IS READ FROM THE DATABASE FILE AND SENT TO THE REMOTE SYSTEM. 
Cx THIS IS REPEATED UNTIL END OF FILE IS REACHED ON THE DATABASE 
Cx FILE. AT END OF FILE, THE PROGRAM DEVICE IS INVITED AND 

Cx CONTROL GOES TO RECDTA TO GET DATA FROM THE REMOTE SYSTEM. 


Cx 

CRRA K ARK RIK KKK KER KIRK IKK KK KIKI A KIRK KIKI KIKI ARIK IK KIA KIA 
(eg 4 | 

C SENDTA TAG 

Cc READ DBFILE 98 

C 98 EXSR INVSND INVITE 

C EOFPSW IFNE '1' 

C MOVE DBDATA SNDFLD 

C EXSR WCFRTN 

C GOTO SENDTA SEND DATA 

C END 

CR KKK RK RIK KKK KKK KR KI KKK KAKI KKK IKI KIRK AKI KKK I KIKI 
Cx 

Cx RECEIVE RECORDS FROM THE REMOTE SYSTEM UNTIL THE RCVDETACH 


Cx INDICATOR IS SET ON. EACH RECORD RECEIVED IS PRINTED TO 
Cx THE PRINT FILE. 


C* 

CRRA KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK K IK IKI KKK EKER ERK KKK 
c+ Bl 

Cc RECDTA TAG 

¢ READ SRCICF 98 


CHR KAKA KA KR KKK KEK KIRK RAK IK KIKI KIKI KKK KIKI IKI I KIRKE RIERA. 
Cx 

Cx IF ANY ICF FILE ERROR OCCURS, PRINT A LINE CONTAINING 

Cx INFORMATION ABOUT THE ERROR. 


Cx 

CHR KAKA KA KRHA KK KIKI KK KKK KKEK ERIK IKI KKK KERIKERI KIKI K ERIK IERIE. 
*G 

Le MAJCOD CABGT'03' NOTOKR 

C MAJCOD CABEQ'03' CHKDET NO DATA? 

C EXCPTPTREC 

C CHKDET TAG 

C *IN35 CABNE'1' RECDTA DETACH? 


CRRA KK RIK RIK KKK KKK KKK KKK KKK K KKK IKI KKK KIKI KIKI AK IKK IK, 
Cx 

Cx AFTER A DETACH INDICATION IS RECEIVED, AN EOJ MESSAGE 

C* IS PRINTED AND THE SESSION IS ENDED. 

Cx 


ICF Programming V4R1 


10/14/87 


03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/16/87 


03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
03/20/89 
03/20/89 
0/14/87 
03/20/89 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 


H000000 


CARA KARR K KKK KKK KK KKK KKK KKK KKK KKK IK KK IK IKK KKK KKK KE KERR KKK RR 


(ea 7 | 
c 
c 


EXCPTOKEND 
GOTO END 


CARA KKK KK KKK KKK KKK KKK KKK KKK KKK KKK IK IK IKK KKK KK KIRKE KERR RRR 


Cx 


Cx WHEN AN ERROR OCCURS ON AN ICF SESSION, INFORMATION 
Cx ABOUT THE ERROR IS PRINTED. 


Cx 


CRRA RAR K KKK KKK KKK KKK KKK KKK KKK KKK KK KK IK KIKI KKK ERE KERR RRR RK 


C* Bf 
c 
C 


NOTOKR 


TAG 
EXCPTNOTOK 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI IKK EKER ERIKA 


Cx 


Cx WHEN PROCESSING IS FINISHED, THE LAST RECORD SWITCH 
Cx IS TURNED ON AND THE PROGRAM IS ENDED. 


Cx 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK RIK IKI KKK IRIE RK KK IRR 


c* 
c 


Cc 
Cc 


END 


TAG 
SETON LR 
RETRN 


CRRA KKK KK KKK KKK KKK KKK KEK EKER KKK KK KKK KKK KKK IKK KKK KKK IERIE KERR KERR 


Cx 


Cx THIS SUBROUTINE SENDS DATA TO THE REMOTE SYSTEM. 


Cx 


CR KAR KKK KK KKK KKK KKK KKK EKER EKER KKK KKK KK KK IK IK KKK KKK IR ERIE ERE KEK 


c+ 
c 


C 
C MAJCOD 
C 


WCFRTN 


BEGSR 

WRITESNDDATA 
CABGT'03' NOTOKR 
ENDSR 


CRRA RAR KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IRE RRR ERE RRR 


Cx 


Cx THIS SUBROUTINE IS CALLED AT END OF FILE TO REQUEST THE REMOTE 
Cx PROGRAM TO START SENDING DATA. AN INVITE OPERATION IS ISSUED 


C* TO NOTIFY THE TARGET PROGRAM THAT IT CAN START SENDING DATA. 
Cx 

CARA RRR KKK KKK KKK KKK KKK KKK EKER KKK KK KKK KKK KKK KK KIKI KIKI RIERE KERR K ERK 
C* 

C INVSND BEGSR 

C MOVE '1' EOFPSW 1 

C MOVE '1' *IN45 

C WRITEINVITE 

C MAJCOD CABGT'03' NOTOKR 

C ENDSR 

CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERE KER RK KKK 
OQPRINT E 1 PTREC 

0 RCVFLD 80 

0 Ed OKEND 

0 21 'RSDBAT HAS COMPLETED ' 
0 30 'NORMALLY.' 

0 ee NOTOK 

0 21 'RSDBAT HAS COMPLETED ' 
0 32 'ABNORMALLY.' 

0 MAJCOD 35 

0 36 '/' 

0 MINCOD 39 

0 46 ‘FORMAT: 

0 FMTNM 56 

0 63 ‘DEVICE: 

0 PGMDEV 80 

14501 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 


OUTPUT FIELDS FOR RECORD SNDDATA FILE 


SNDFLD 80 
OUTPUT FIELDS FOR RECORD EVOKPGM FILE 
PGMID 10 
LIB 20 


SRCICF FORMAT SNDDATA. 


CHAR 80 
SRCICF FORMAT EVOKPGM. 
CHAR 10 
CHAR 10 


OUTPUT FIELDS FOR RECORD INVITE FILE SRCICF FORMAT INVITE. 


x*x*e*x*x END OF SOURCE 


kk Kk KK 


10/14/87 
10/14/87 
10/14/87 
10/14/87 


0/14/87 
03/20/89 
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Additional Diagnostic Messages 
* 7089 1100 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE SRCICF. 
* 7086 1300 RPG PROVIDES BLOCK OR UNBLOCK SUPPORT FOR FILE DBFILE. 


Cross Reference 
File and Record References: 


FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 
02 DBFILE DISK 1300D 1500 4900 
03 QPRINT PRINTER 1400D 13100 13300 13600 14501 
01 SRCICF WORKSTN 1100D 6500 
ENDREC 1100D DO00000 
EVOKPGM 1100D Cco00000 3500 G000000 
INVITE 1100D E000000 12700 000000 
RCVDATA 1100D A000000 
SNDDATA 1100D Bo00000 11300 FO00000 
Field References 
FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 
*IN35 A(1) 7700 
*IN45 A(1) 12600M 
*IN50 A(1) 3400M 3600M 
CHKDET TAG 7400 7600D 
DBDATA A(80) 1600D 5200 
END TAG 8600 10300D 
EOFPSW A(1) 5100 12500D 
FEEDBK DS (404) 1100 1800D 
FMTNM A(8) 1900D 14300 
INVSND BEGSR 5000 12400D 
* 7031 ITMIN TAG 3100D 
LIB A(10) 3300M GQ00002D 
MAJCOD A(2) 2200D 3700 7300 7400 11400 
12800 13900 
* 7031 MAJMIN A(4) 2100D 
MINCOD A(2) 2300D 14100 
NOTOK EXCPT 9500 13600 
NOTOKR TAG 3700 7300 9400D 11400 12800 
OKEND EXCPT 8500 13300 
PGMDEV A(10) 2000D 14500 
PGMID A(10) 3200M GQ00001D 
PTREC EXCPT 7500 13100 
RCVFLD A(80 AQ00001D 13200 
RECDTA TAG 6400D 7700 
SENDTA TAG 4800D 5400 
SNDFLD A(80 BQ00001D 5200M FOQ0001D 
WCFRTN BEGSR 5300 11200D 
‘ICFLIB =| LITERAL 3300 
"RTIDBATCL' LITERAL 3200 


‘@' LITERAL 3600 
'03' LITERAL 3700 7300 7400 11400 12800 
ori LITERAL 3400 5100 7700 12500 12600 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


*IN 3400M 3600M 7700 12600M 
LR 10400M 
OA 1400D =14501 
* 7031 15 
* 7031 30 
35 7700 
45 12600M 
50 3400M 3600M 
* 7031 80 1500M 
98 4900M 5000 6500M 


eee *e* END OF CROSS REFERENCE ** * * * 
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Message Summary 
* QRG6103 Severity: 00 Number: 1 


Message... . : No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 5 
Message... .: The Name or indicator is not referenced. 
* QRG7086 Severity: 00 Number: 1 
Message... . : The RPG handles blocking function for file. 


INFDS contents updated only when blocks of data transferred. 
* QRG7089 Severity: 00 Number: 1 
Message... .: The RPG provides Separate-Indicator area for 
file. 
e**e***e* END OF MESSAGE SUMMARY ** * * * 


Final Summary 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


8 8 0 0 0 0 0 
Program Source Totals: 
RECOMS ir eos es ee Sere ep eee 145 
Specifications ......: 66 
Table Records. ......: O 
Comments . we ee ee eg 79 


PRM has been called. 
Program RSDBAT is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**x*e*e* END OF COMPILATION ** * * * 
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Compiler... ....... 4... 2 IBM AS/400 RPG/400 
Command Options: 


Program ......... 4... 2  ICFLIB/RSFBAT 
Source file .......... :  ICFLIB/QICFPUB 
Source member ......... :  *PGM 
Text not available for message RXT0073 file QRPGMSG. 
Generation options. ...... :  *NOLIST *NOXREF *NOATR *NODUMP 
Source listing indentation... :  ¥*NONE 
SAA flagging. ......... : + *NOFLAG 
Generation severity level ...: 9 
Print: Til@.. «4.4% GA ee ef OAEIBL/QSYSPRT 
Replace program ........:  *YES 
Target release... ...... : +  *CURRENT 
User profile. .........: ¥*USER 
Authority ........... 3:  *LIBCRTAUT 
TEX 6 cee ite, ee ere et we we a 3 RSRCMBRTXT, 
Phase trace ..........: = *NO 
Intermediate text dump... ..:  *NONE 
Snap dump ........... :  *NONE 
Codelist..........2.2.: = *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member... ....... +... :  RSFBAT 
FATS cs ee, dae ot se ee we SP. SQTCEPUB 
ETDPAaRY:. os wise cee ey a ee  SECELIB 
Last Change .......... : 03/20/89 15:30:19 
Description .......... : rpg batch file transfer using $$FORMAT 
Source Listing 
100 H&K AKA K KKK KKK KERR KK ERK KKK KKK KKK ERK KKK ERE KKK ERK KRER EK ERR ERR 
200 H* 
300 H* THIS IS A BATCH FILE TRANSFER PROGRAM THAT READS A SEQUENTIAL 
400 H* FILE AND SENDS THE RECORDS TO THE REMOTE SYSTEM UNTIL THE END 
500 H* OF FILE IS REACHED. AT THIS TIME, THE PROGRAM STOPS SENDING 
600 H* AND STARTS RECEIVING RECORDS FROM THE REMOTE SYSTEM UNTIL 
700 H* A DETACH INDICATION IS RECEIVED. 
800 H* 
900 H&K KKK KAA KKK KERR KK ERK KKK KKK KEK ERK KERR RE REK RRR EERE ERE ERRERRREREER 
1000 H« fj 
1100 FSRCICF CF F 84 WORKSTN 
1200 F KINFDS FEEDBK 
1300 FDBFILE IF F 80 DISK 
1400 FQPRINT O F 132 PRINTER 
1500 ISRCICF NS 82 
1600 I 1 80 RCVFLD 
1700 IDBFILE NS 80 
1800 I 1 80 DBDATA 
1900 Ix] 
2000 IFEEDBK DS 
2100 I 38 45 FMTNM 
2200 I 273 282 PGMDEV 
2300 I 401 404 MAJMIN 
2400 I 401 402 MAJCOD 
2500 I 403 404 MINCOD 
2600 CRRA KKK KKK KKK KKK KKK EK KKK KKK KKK KKK KKK KKK KKK RIK IKI KKK KEE KERR KARR 
2700 Cx 


2800 Cx EVOKE PROGRAM 'RTFBATCL' ON REMOTE SYSTEM IN LIBRARY ICFLIB. 
2900 Cx THE USER ID AND PASSWORD ARE DEFINED AS PART OF THE $$EVOKNI 
3000 Cx FORMAT. 


3100 Cx 
3200 CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KI KIKI KKK IER KKK IRE 
3300 Cx Ky 

3400 C ITMIN TAG 

3500 C EXCPTEVOKE ISSUE EVOKE 
3600 C MAJCOD —- CABGT'03' NOTOKR ERROR? 


*NOOPTIMIZE 
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CARH KKK ARK RK KEKE KAKI KK KKK KERRIER IER IKI KAR IK ERIE KIKI R IKI A KIRK ER ER 
Cx 

Cx AFTER THE SUCCESSFUL EXECUTION OF THE EVOKE OPERATION, A 

Cx RECORD IS READ FROM THE DATABASE FILE, AND SENT TO THE REMOTE 
Cx = SYSTEM. THIS IS REPEATED UNTIL AN END OF FILE IS REACHED ON 
Cx THE DATABASE FILE. AT THIS TIME, THE PROGRAM DEVICE IS INVI- 
Cx TED, AND CONTROL GOES TO RECDTA TO GET DATA FROM THE REMOTE 
Cx SYSTEM. 


Cx 

CK AKA RK RIK KKK KKK IK KKK IKK IKK IK KK IKK KIA KIKI RIKKI AKI KIRK. 
(eg 4 | 

C SENDTA TAG 

C READ DBFILE 98 

C 98 EXSR INVSND INVITE 

C EOFPSW IFNE '1' 

C EXSR WCFRTN 

C GOTO SENDTA SEND DATA 

C END 

CR KKK ARK RIK KA KR KR KI KKK KIA KAKA K KIKI IKI IKARIA KI AK 
Cx 

Cx THE PROGRAM STARTS RECEIVING RECORDS AT THIS POINT FROM THE 


Cx REMOTE SYSTEM UNTIL A DETACH INDICATION IS RECEIVED. EACH 
Cx RECORD RECEIVED IS PRINTED TO THE PRINT FILE. 
Cx 


CRRA KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK RIK KKK KK EKER ERK KARI 


c« 

C RECDTA TAG 

c READ SRCICF 98 

CRRA RAKE KKK KEKE KKK KKK KKK KKK KKK KKK IKK KKK EKER IER KKK ARIK 
C* 

C* IF AN ICF FILE ERROR OCCURS, PRINT A LINE CONTAINING 


C* INFORMATION ABOUT THE ERROR. 

Cx 

CRRA KARR K KKK KKK KKK KKK KKK KK KKK KK IK KKK KKK KKK KIKI IKK EKER ERK KKK IR 
(ee 6 | 

C MAJCOD CABGT'03' NOTOKR 

C MAJCOD CABEQ'03' CHKDET NO DATA? 
Cc EXCPTPTREC 

C CHKDET TAG 

Cc MINCOD CABNE'08' RECDTA DETACH? 
CRRA KKK KK KKK KKK KKK KKK KKK KKK KKK KKK IK KK IK IKK KKK KKK KEKE RRR RIKER 


Cx 
Cx AFTER A DETACH INDICATION IS RECEIVED, AN EOJ MESSAGE IS 
Cx PRINTED AND THE SESSION IS ENDED. 


Cx 

CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IKK KKK KKK KKK KKK ERE KERR KKK RR 
c* 

C EXCPTOKEND 

C GOTO END 

CRRA KKK KK KKK KKK KKK KKK KKK KKK KKK KKK IK KK IK IKK KKK KKK KERR KKK 


Cx 

Cx WHEN AN ERROR OCCURS ON AN ICF SESSION, INFORMATION 
Cx ABOUT THE ERROR IS PRINTED. 

Cx 


CRRA KAKA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK EKER ERR KKK RK 


C* & 

C NOTOKR TAG 

C EXCPTNOTOK 

CRRA KARR KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KK KKK EKER ERK KK RRR 
Cx 

Cx WHEN PROCESSING IS FINISHED, THE LAST RECORD SWITCH IS 

Cx TURNED ON AND THE PROGRAM IS ENDED. 


C* 

CRRA KARR K KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI IKK KKK KKK IR 
c* 

C END TAG 

C SETON LR 

C RETRN 


10/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/16/87 
0/16/87 
0/16/87 
3 0/16/87 
0/16/87 
BO01 0/16/87 
001 0/16/87 
001 0/16/87 
E001 0/16/87 
0/16/87 


03/20/89 


03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
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0500 Cer RII III III ICI III ICICI IIIA IIIA IR IIA IK 
0600 Cx 

0700 Cx THIS SUBROUTINE SENDS DATA TO THE REMOTE SYSTEM. 

0800 Cx 


Q9DD C&R KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK EK KEK KKK KKK KIKI KIKI IKKE ERR 


1000 Cx 
C 


1100 WCFRTN BEGSR 

1200 C EXCPTSNDATA 

1300 C MAJCOD CABGT'03' NOTOKR 

1400 C ENDSR 

COMIC et Eee a eS Se Se SS 
1600 Cx 


1700 C* THIS SUBROUTINE IS CALLED AT END OF FILE TO REQUEST THE REMOTE 
1800 C* PROGRAM TO START SENDING DATA. AN INVITE OPERATION IS ISSUED 
1900 C* TO NOTIFY THE TARGET PROGRAM THAT IT CAN START SENDING DATA. 


21DQ C&R KK KK KKK KKK KEK KKK KK KKK KKK KKK KKK KKK KKK EKER EKER KKK KKK IK IKI 


2200 Cx 
C 


2300 INVSND BEGSR 

2400 C MOVE '1' EOFPSW 1 
2500 C EXCPTINVITE 

2600 C MAJCOD CABGT'03' NOTOKR 

2700 C ENDSR 

ZBOO Ce A I II IH KI IK KK I I IK KI ITOK KI IT I KK II TOR KI I TK KIKI IK KI 
2900 OQPRINT E 1 PTREC 

3000 0 RCVFLD 80 

3100 0 El OKEND 

3200 0 21 'RSFBAT HAS COMPLETED ' 
3300 0 30 'NORMALLY.' 
3400 0 Ed NOTOK 

3500 0 21 'RSFBAT HAS COMPLETED ' 
3600 0 32 'ABNORMALLY.' 
3700 0 MAJCOD 35 

3800 0 36 '/' 

3900 0 MINCOD 39 

4000 0 46 'FORMAT:' 
4100 0 FMTNM 56 

4200 0 63 'DEVICE:' 
4300 0 PGMDEV 80 

4400 OSRCICF E EVOKE 

4500 0 K8 '$$EVOKNI' 
4600 0 8 'RTFBATCL' 
4700 0 16 'QSECOFR ' 
4800 0 24 'QSECOFR ' 
4900 0 32 'ICFLIB ' 
5000 0 E SNDATA 

5100 0 K8 '$$SENDNI' 
5200 0 4 '0080' 

5300 0 DBDATA 84 

5400 0 E INVITE 

5500 0 K6 '$$SEND' 
5600 0 4 '0000' 


* 6103 15601 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 
x**e**e** END OF SOURCE ** * * * 
Additional Diagnostic Messages 

* 7089 1100 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE SRCICF. 

* 7086 1300 RPG PROVIDES BLOCK OR UNBLOCK SUPPORT FOR FILE DBFILE. 


Cross Reference 
File and Record References: 
FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 


02 DBFILE DISK 1300D 1700 4900 

03 QPRINT PRINTER 1400D 12900 13100 13400 15601 

01 SRCICF WORKSTN 1100D 1500 6400 14400 15000 15400 
$$EVOKNI 14500 
$$SEND 15500 
$$SENDNI 15100 
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Field References: 


FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 

CHKDET TAG 7300 7500D 

DBDATA A(80) 1800D 15300 

END TAG 8500 10200D 

EOFPSW A(1) 5100 12400D 

EVOKE EXCPT 3500 14400 

FEEDBK DS(404) 1100  2000D 

FMTNM A(8) 2100D 14100 

INVITE EXCPT 12500 15400 

INVSND BEGSR 5000 12300D 
* 7031 ITMIN TAG 3400D 

MAJCOD A(2) 2400D 3600 7200 7300 11300 12600 13700 
* 7031 MAJMIN A(4) 2300D 

MINCOD A(2) 2500D 7600 13900 

NOTOK EXCPT 9400 13400 

NOTOKR TAG 3600 7200 9300D 11300 12600 

OKEND EXCPT 8400 13100 

PGMDEV A(10) 2200D 14300 

PTREC EXCPT 7400 12900 

RCVFLD A(80) 1600D 13000 

RECDTA TAG 6300D 7600 

SENDTA TAG 4800D 5300 

SNDATA EXCPT 11200 15000 

WCFRTN BEGSR 5200 11100D 

'03' LITERAL 3600 7200 7300 11300 12600 

'08' LITERAL 7600 

a4 LITERAL 5100 12400 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


LR 10300M 
OA 400D 15601 
* 7031 80 700M 
* 7031 82 500M 
98 4900M 5000 6400M 


eee *e* END OF CROSS REFERENCE *** * * 


Message Summary 


* QRG6103 Severity: 00 Number: 

Message... . : No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 4 
Message... .: The Name or indicator is not referenced. 
* QRG7086 Severity: 00 Number: 

Message . ... : The RPG handles blocking function for file. 

INFDS contents updated only when blocks of data transferred. 
* QRG7089 Severity: 00 Number: 


Message... . : The RPG provides Separate-Indicator area for 
file. 
x***** END OF MESSAGE SUMMARY * * * * * 


Final Summary 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


7 7 0 0 0 0 0 
Program Source Totals: 
ReCORdS: oe ses ket ee eee) E56 
Specifications. <6 644 <2 75 
Table Records .......: O 
Comments .........: 481 


PRM has been called. 
Program RSFBAT is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**x*e*e* END OF COMPILATION ** * * * 
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Target Program Batch Transfer (Example 1): The 
following describes an RPG/400 batch data transfer target 
program. 


Program Files: The RPG/400 batch transfer target program 
uses the following files: 


TGTICF 
An ICF file used to send records to and receive 
records from the source program. 


DBFILE 
A database file that contains the records to be sent 
to the source program. 


QPRINT 
A printer file used to print the records received from 
the source program. 


DDS Source: The DDS used in the ICF file is illustrated in 
the following example. The other files (DBFILE and 
QPRINT) are program-described and therefore do not require 
DDS. 


[SEES TO SIO IOC I TOI ICE ITO I TTI ITI I III III 


Ax * 
Ax ICF FILE * 
Ax USED IN BATCH DATA TRANSFER PROGRAM * 
Ax * 


[REE ICSE IOS ISI IOC IOS IOC I TOI ICI TOI III ITI I III III 
Ax 

Ax FILE LEVEL INDICATORS: 

Ax 


A INDARA 
Ax 
A RCVTRNRND(15 ‘END OF DATA‘) 
Ax 
A 30 DETACH 
Ax 
A INDTXT(30 '30->DETACH TARG- 
A ET PROGRAM. ') 
Ax 
A RCVDETACH(35 ‘RECEIVED - 
A DETACHED. ') 
Ax 
Ax 
DKK KKK I KIRK KR KKK KK RIK KEI KKK IK KKK KIKI KKK IKK KIKI KKK IKK KKK RK, 
Ax ICF RECORD FORMATS * 
DKK KI RIK KKK KK KK RIKKI K KKK IK KKK KIKI KKK IKKE IKKE IK KKK KKK KEK, 

R RCVDATA 

RCVFLD 80A 
R SNDDATA 
SNDFLD 80A 

R EVOKPGM 
A 50 EVOKE (&LIB/&PGMID) 
A 50 SECURITY(2 'PASSWRD' + 

3 'USERID') 

A PGMID 10A P 
A LIB 10A P 
A R_ ENDREC 
A R INVITE 
A 45 INVITE 


This example acquires all program devices at the beginning 
of the program. For performance considerations, you may 
not want to acquire program devices until they are actually 
needed in the program. 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/TGTICF) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(TGTICF) ACQPGMDEV (PGMDEVB) 
TEXT('TARGET ICF FILE FOR BATCH DATA TRANSFER') 


The command needed to define the program device entry is: 


ADDICFDEVE FILE(ICFLIB/TGTICF) PGMDEV(PGMDEVB) 
RMTLOCNAME (*REQUESTER) 
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Program Explanation: The following describes the struc- 
ture of the program examples illustrated in Figure 11-11 on 
page 11-18 and Figure 11-12 on page 11-22. The ICF file 
used in the first example is defined by the user and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference letters in 
the explanation below correspond to those in the following 
program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the use of user- 
defined formats and system-supplied formats. All output 
operations to the ICF file in the first example are done using 
the WRITE statement. All output operations to the ICF file in 
the second example using system-supplied formats are done 
using the EXCPT statement. 


Differences between the first and second example are 
described in notes in each of the descriptions. 


The file specification identifies the files used in the 
program. TGTICF is the ICF file used to send records 
to the source program. 


The files used in the program are opened at the begin- 
ning of the RPG/400 cycle and the ICF program device 
is implicitly acquired because the ACQPGMDEV 
parameter was specified on the CRTICFF command. 


Note: In the program using system-supplied formats, 
the input records for TGTICF are explicitly coded since 
TGTICF is treated as a program-described file. The 
system-supplied file, QICDMF, can be be used instead 
of TGTICF. Using the system-supplied file is done by 
specifying QICDMF in the file specification, or by using 
an OVRICFF command to change the file name from 
TGTICF to QICDMF. The OVRICFF command can 
also be used to change the ACQPGMDEV parameter 
of the file. 


fA s~FEEDBK is the name of the file information data struc- 
ture (INFDS) used with TGTICF. It contains the fol- 
lowing information: 


e Record format-name (FMTNM) 

e Program device name (PGMDEV) 

e Major/minor return code (MAJMIN, MAJCOD, 
MINCOD) 


Read data from the ICF program device (TGTICEF) file. 


If an error occurs on the read (major return code 
greater than 03), control passes to [J. Otherwise, if 
data is received (major return code not = 03), the data 
is written to the printer file (QPRINT). 


Data records are read until the change-direction indi- 
cation is received from the source program. When 
change direction is received, indicator 15 is set on, as 
defined by the RCVTRNRND keyword in the DDS for 
the ICF file, and control is passed to [j. 


Note: In the program using system-supplied formats, 
the minor return code of '00' is checked to verify 
whether change direction is received. 


The database file is read and the records sent to the 
source program until the end of the database file. At 
this time, the program sets indicator 98 and goes to 


EJ. After returning from J, control is passed to Mj. 


If it is not the last record, the data is moved to field 
SNDEFLD, and the program goes to [¥ to write the 
record to the ICF program device. When control 

returns from J, the next database record is read. 


After the last database record has been read, the fol- 
lowing message is written to the printer file: 

RTDBAT HAS COMPLETED NORMALLY 

Control passes to J. 

Note: The program name is RSFBAT in the program 
using system-supplied formats. 


When an I/O operation to the ICF file (TGTICF) com- 
pletes unsuccessfully, the following message is written 
to the printer file: 


RTDBAT HAS COMPLETED ABNORMALLY 
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Control passes to gj. 


Note: The program name is RTFBAT in the program 
using system-supplied formats. 


The program ends the job by setting on the LR indi- 
cator and returning to caller of the program. The ICF 
file is closed and the session is ended at the end of the 
RPG cycle. 


This subroutine is called to write data to the ICF 
program device using the format SNDDATA. If an 
error occurs, the program goes to [J and a message 
is printed. 

Note: The $$SENDNI format is used instead of the 


user-defined SNDDATA format in the program using 
system-supplied formats. 


This subroutine is called to issue a detach request to 
the ICF program device using format ENDREC. If an 
error occurs, the program goes to [J and a message 
is printed. 


Note: The $$SENDET format is used instead of the 
user-defined ENDREC format in the program using 
system-supplied formats. 
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Compiler 

Command Options: 
Program 
Source file 
Source member 


Text not available for message RXT0073 file QRPGMSG. 


Generation options. ......: 
Source listing indentation ...: 
SAA flagging 
Generation severity level 
Print file 
Replace program 
Target release 
User profile 
Authority 
Text 
Phase trace 
Intermediate text dump 
Snap dump 
Codelist 
Ignore decimal data error 
Actual Program Source: 
Member 


Library 
Last Change 
Description 


Source 


*NOLIST 
*NONE 
*NOFLAG 
9 
*LIBL/QSYSPRT 
*YES 
*CURRENT 
*USER 
*LIBCRTAUT 
*SRCMBRTXT 
*NO 

*NONE 
*NONE 
*NONE 

*NO 


*NOXREF *NOATR 


RTDBAT 

QICFPUB 

ICFLIB 

03/20/89 15:40:57 

rpg batch file transfer using dds so 


Listing 


100 H&K KKK K KAKA K KK ARK KKK KEKE KKK KKK KEK ERK KERR KEE KEK ERK EERE EKER ERR RE RRREREER 
200 Hx 
300 H* THIS PROGRAM IS EVOKED BY THE SOURCE PROGRAM AND RECEIVES 
400 H* RECORDS FROM IT. WHEN THE SOURCE PROGRAM IS DONE SENDING 
500 H* DATA, THIS PROGRAM SENDS ITS OWN RECORDS. WHEN FINISHED, 
600 H* THIS PROGRAM WILL SEND A DETACH REQUEST TO THE SOURCE 
700 H* PROGRAM TO END THE SESSION AND JOB. 
800 H« 
900 H&K KKK K KKK KKK KERR KK ERK KKK KKK KKK ERK KERR ERE KKK ERK RRR KEE RRA RRR REREER 
1000 « 
H 
1100 FIGTICF CF E WORKSTN 
1200 F KINFDS FEEDBK 
RECORD FORMAT(S): LIBRARY ICFLIB FILE TGTICF. 
EXTERNAL FORMAT RCVDATA RPG NAME RCVDATA 
EXTERNAL FORMAT SNDDATA RPG NAME SNDDATA 
EXTERNAL FORMAT EVOKPGM RPG NAME EVOKPGM 
EXTERNAL FORMAT ENDREC RPG NAME ENDREC 
EXTERNAL FORMAT INVITE RPG NAME INVITE 
1300 FDBFILE IF F 80 DISK 
1400 FQPRINT O F 132 PRINTER 
1500 IDBFILE NS 80 
1600 I 1 80 DBDATA 
1700 Ix] 
AQ0000@ INPUT FIELDS FOR RECORD RCVDATA FILE TGTICF FORMAT RCVDATA. 
AQ00001 1 80 RCVFLD 
B0Q0000 INPUT FIELDS FOR RECORD SNDDATA FILE TGTICF FORMAT SNDDATA. 
B000001 1 80 SNDFLD 
C000000 INPUT FIELDS FOR RECORD EVOKPGM FILE TGTICF FORMAT EVOKPGM. 
DeQ0000 INPUT FIELDS FOR RECORD ENDREC FILE TGTICF FORMAT ENDREC. 
£000000 INPUT FIELDS FOR RECORD INVITE FILE TGTICF FORMAT INVITE. 
1800 IFEEDBK DS 
1900 I 38 45 FMTNM 
2000 I 273 282 PGMDEV 
2100 I 401 404 MAJMIN 
2200 1 401 402 MAJCOD 
2300 I 403 404 MINCOD 


Figure 11-11 (Part 1 of 4). 
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*NODUMP *NOOPTIMIZE 


urce 


10/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
10/16/87 


10/16/87 
10/16/87 


10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 


10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 
10/16/87 


Target Program Example — RTDBAT (User-Defined Formats) 


KKK 


CARH RHA K AKA K KEKE KAKA KK KR KKK KIKI RAKE KKK IRR IK IKARIA IKIER IRIE 
Cx 

Cx THIS PROGRAM ISSUES A READ OPERATION TO THE PROGRAM DEVICE 
C* TO RECEIVE RECORDS FROM THE SOURCE PROGRAM UNTIL THE 

C*  RCVTRNRND INDICATOR (*IN15) IS SET. EACH RECORD RECEIVED IS 


2900 C* PRINTED TO THE PRINT FILE. 
3000 Cx 

3100 C* IF AN ERROR OCCURS, AN ERROR MESSAGE IS PRINTED AND THE 
3200 C* JOB IS ENDED. 

3300 Cx 

3400 CRRA KKK KKK KKK KKK KKK KE KKK KKK KKK KK KKK KKK KKK KKK KKK KKK IERIE RE RE RRR 
3500 Cx §y 

3600 C RECDTA —TAG 

3700 C READ TGTICF 98 

3800 C MAJCOD —- CABGT'@3' NOTOKR ERROR? 
3900 C MAJCOD — CABEQ'03' CHKTRN NO DATA ? 
4000 C EXCPTPTREC 

4100 C CHKTRN — TAG 

4200 C *INI5 CABNE'1' RECDTA RCVTRNRND ? 
4300 CRRA KARR K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IKI I KIKI KIER ER KKK RRR 
4400 Cx 

4500 C* WHEN A RCVTRNRND INDICATION IS RECEIVED, THE PROGRAM STARTS 
4600 C* SENDING THE RECORDS TO THE SOURCE PROGRAM. RECORDS ARE SENT 
4700 C* UNTIL AN END OF FILE IS REACHED ON THE DATABASE FILE. AT 
4800 C* THIS TIME, A DETACH REQUEST IS SENT TO THE SOURCE PROGRAM. 
4900 Cx 


BOOO Cx mR KKK KIRK KKK RK KKK KKK KKK IKK IKK KKK IKK IK KK KIKI KAKI ARK 
5100 cx fy 

5200 C SENDTA TAG 

5300 C READ DBFILE 98 

5400 C 98 EXSR ENDSES SEND DETACH 
5500 C EOFPSW IFNE '1' 

5600 C MOVE DBDATA SNDFLD 

5700 C EXSR WCFRTN 

5800 C GOTO SENDTA SEND DATA 
5900 C END 

6000 Cire ICICI III IIA RR I 
6100 Cx 

6200 C* WHEN THE END OF FILE IS REACHED, AN EOJ MESSAGE IS 

6300 C* PRINTED AND THE PROGRAM GOES TO END. 

6400 Cx 

6500 Cio I III III III ICI ICR III ICI IR IIIA IR I I 
6600 Cx fy 

6700 C EXCPTOKEND 

6800 C GOTO END 

6900 Cer rE III III III III ICICI ICICI IIA ARI I 
7000 Cx 

7100 C* WHEN AN I/0 OPERATION ERROR IS DETECTED, AN ABNORMAL 

7200 C* TERMINATION MESSAGE IS PRINTED AND THE PROGRAM ENDS. 

7300 Cx 

7400 Cnr III II III III IR IIIA III CIR IIA RR I I. 
7500 Cx fi 

7600 C NOTOKR TAG 

7700 C EXCPTNOTOK 

TBOO C&R RRR KR KR KIRK KR KKK IK KAKA KIRK ARIK KIA KIKI KK IK IKI KAKI ARIA IKK 
7900 Cx 

8000 C* WHEN PROCESSING IS FINISHED, THE LAST RECORD SWITCH IS SET 
8100 C* AND THE PROGRAM IS ENDED. 

8200 Cx 

B30Q Cm KKK RK KKK KRKRKRK KKK KK KKK KKK KKK IKK KKK IKK KIKI AK IKK IKK IK 
8400 Cx Ed 

8500 C END TAG 

8600 C SETON LR 

8700 C RETRN 


10/16/87 


03/20/89 
0/16/87 
0/16/87 
0/16/87 
0/16/87 


Figure 11-11 (Part 2 of 4). Target Program Example — RTDBAT (User-Defined Formats) 
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G000000 


* 7089 
* 7086 


CK AKA RIK RIK KKK KKK IK KKK IK KKK KKK IKI KIRK IKK KIKI I KIA KIRK IKK IK 

Cx 

Cx THIS SUBROUTINE IS CALLED TO SEND DATA TO THE SOURCE PRO- 

Cx GRAM. IF A SESSION ERROR OCCURS, AN ABNORMAL TERMINATION 

Cx MESSAGE IS PRINTED, THE LR SWITCH IS SET, AND THE JOB ENDS. 

Cx 

CR KAKA RIK RIK KKK KR KIKI K KIRK IKK KKK IKI KI KK IKK KIKI KIKI A RIKKI RIK 

C* Bf 

C WCFRTN BEGSR 

C WRITESNDDATA 

C MAJCOD CABGT'03' NOTOKR ERROR? 

C ENDSR 

CRRA RIK RIK KR KK KKK KKK KKK IKK KKK IKI KK KIA KI IKI KIKI A KIRK IK, 

Cx 

C* THIS SUBROUTINE IS CALLED AT END OF FILE TO SEND AN 

C* INDICATION TO THE SOURCE SYSTEM THAT TRANSMISSION IS ENDED. 

C* THE END OF FILE SWITCH IS ALSO SET TO END THE JOB. 

Cx 

CRRA K ARIK RIK KKK KR KI KKK KIA KKK KKK KKK IK IKK IA KIKI KIKI A KIRK IK 

c* 

C ENDSES BEGSR 

C MOVE '1' *IN30 ACTV DETACH 

C MOVE '1' EOFPSW 1 

Cc WRITEENDREC SEND DETACH 

C MAJCOD CABGT'03' NOTOKR ERROR? 

C ENDSR 

CRRA KA RK RIK KR KR KR KKK KKK IARI KKK IKK KIKI IKARIA KIKI K KIA KAR 

OQPRINT E 1 PTREC 

0 RCVFLD 80 

0 El OKEND 

0 21 'RTDBAT HAS COMPLETED ' 

0 30 'NORMALLY.' 

0 El NOTOK 

0 21 'RTDBAT HAS COMPLETED ' 

0 32 'ABNORMALLY.' 

0 MAJCOD 37 

0 38 '/' 

0 MINCOD 40 

0 49 'FORMAT:' 

0 FMTNM 60 

0 69 'DEVICE:' 

0 PGMDEV 80 

12901 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 

OUTPUT FIELDS FOR RECORD SNDDATA FILE TGTICF FORMAT SNDDATA. 
SNDFLD 80 CHAR 80 


OUTPUT FIELDS FOR RECORD ENDREC FILE TGTICF FORMAT ENDREC. 
kee ee END OF SOURCE ** * * % 


Additional Diagnostic Messages 
1100 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE TGTICF. 
1300 RPG PROVIDES BLOCK OR UNBLOCK SUPPORT FOR FILE DBFILE. 

Cross Reference 


File and Record References: 
FILE/RCD DEV/RCD 


REFERENCES (D=DEFINED) 


02 DBFILE DISK 1300D 500 5300 
03 QPRINT PRINTER 1400D 11500 11700 12000 12901 
01 TGTICF WORKSTN 1100D 3700 

ENDREC 1100D DO00000 11100 G000000 

EVOKPGM 1100D Co000000 

INVITE 1100D £000000 

RCVDATA 1100D A000000 

SNDDATA 1100D B000000 9700 F000000 


Figure 11-11 (Part 3 of 4). Target Program Example — RTDBAT (User-Defined Formats) 
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10/16/87 


0/16/87 
03/20/89 


Field References: 


FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 
*IN15 A(1) 4200 
*IN30 A(1) 10900M 
CHKTRN TAG 3900 4100D 
DBDATA A(80) 1600D 5600 
END TAG 6800 8500D 
ENDSES BEGSR 5400 10800D 
EOFPSW A(1) 5500 11000D 
FEEDBK DS (404) 1100 1800D 
FMTNM A(8) 1900D 12700 
MAJCOD A(2) 2200D 3800 3900 9800 11200 
12300 
* 7031 MAJMIN A(4) 2100D 
MINCOD A(2) 2300D 12500 
NOTOK EXCPT 7700 12000 
NOTOKR TAG 3800 7600D 9800 11200 
OKEND EXCPT 6700 11700 
PGMDEV A(10) 2000D 12900 
PTREC EXCPT 4000 11500 
RCVFLD A(80) AQ00001D 11600 
RECDTA TAG 3600D 4200 
SENDTA TAG 5200D 5800 
SNDFLD A(80) B000001D 5600M FO00001D 
WCFRTN BEGSR 5700 9600D 
'03' LITERAL 3800 3900 9800 11200 
le LITERAL 4200 5500 10900 11000 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


*IN 4200 10900M 
LR 8600M 
OA 1400D =12901 
15 4200 
30 10900M 
* 7031 35 
* 7031 45 
* 7031 50 
x 7031 80 1500M 
98 3700M 5300M 5400 
xe exe * END OF CROSS REFERENCE ** * * * 


Message 

* QRG6103 Severity: 00 Number: 1 
Message... . : No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 


Summary 


generated. 
* QRG7031 Severity: 00 Number: 5 
Message... .: The Name or indicator is not referenced. 
* QRG7086 Severity: 00 Number: 1 
Message . ... : The RPG handles blocking function for file. 


INFDS contents updated only when blocks of data transferred. 
* QRG7089 Severity: 00 Number: 1 


Message... . : The RPG provides Separate-Indicator area for 
file. 
**e*** END OF MESSAGE SUMMARY * * * * * 
Final Summary 


Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


8 8 0 0 0 0 0 
Program Source Totals: 
RECORKS = ou 6 eee eld te Se 129 
Specifications. <~« «2.4 <4 59 
Table Records. ......3: 0 
Comments: -. a. ee or ee 70 


PRM has been called. 
Program RTDBAT is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**x*e*e* END OF COMPILATION ** * * * 


Figure 11-11 (Part 4 of 4). Target Program Example — RTDBAT (User-Defined Formats) 
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Compiler... ........ 2... 2 IBM AS/400 RPG/400 
Command Options: 


Program ..... 2... 2... 3: ICFLIB/RTFBAT 
Source file .......... :  ICFLIB/QICFPUB 
Source member ......... :  *PGM 
Text not available for message RXT0073 file QRPGMSG. 
Generation options. ...... :  *NOLIST *NOXREF *NOATR *NODUMP 
Source listing indentation... :  ¥*NONE 
SAA flagging. ......... : + *NOFLAG 
Generation severity level ...: 9 
Print: Til@.. «4.4% GA ee ef OAEIBL/QSYSPRT 
Replace program ........:  *YES 
Target release... ...... : +  *CURRENT 
User profile. .........: ¥*USER 
Authority ........... 3:  *LIBCRTAUT 
TEX 6 cee ite, ee ere et we we a 3 RSRCMBRTXT, 
Phase trace ..........: = *NO 
Intermediate text dump... ..:  *NONE 
Snap dump ........... :  *NONE 
Codelist..........2..: = *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member... ...... 6... :  RTFBAT 
FACS cs ee, der ve se ee 2 | SQTCEPUB 
ETDPAaRY:. ose wise cee ey a ee  ICFLIB 
Last Change .......... : 03/20/89 15:15:51 
Description .......... : rpg batch file transfer using $$FORMAT 
SEQUENCE IND 


NUMBER Bee Lise e Pinas Coes t trae Seas Tbe ad hee eg bev eaDnae teen Os tastes Ge heed 
Source Listing 


100 H&K KKK KAKA KKK KKK KKK ERK KKK KKK KKK ERK ERK KR EKER ERK RRR KR ER EKER RR RRRERER 
200 Hx 

300 H* THIS PROGRAM IS EVOKED BY A SOURCE PROGRAM AND RECEIVES 

400 H* RECORDS FROM IT. WHEN THE SOURCE PROGRAM IS DONE SENDING 

500 H* DATA, THIS PROGRAM SENDS ITS OWN RECORDS TO THE SOURCE. 

600 H* WHEN FINISHED, THIS PROGRAM SENDS A DETACH REQUEST TO THE 
700 H* SOURCE PROGRAM TO END THE SESSION AND JOB. 

800 He 

900 H&K KKK KAA KK KK KKK KKK ERK KKK KKK EK ERK RRR KEE RRR ERK KERR KEKE KEKE KER RREER 
1000 H* KJ 

1100 FIGTICF CF F 84 WORKSTN 

1200 F KINFDS FEEDBK 

1300 FDBFILE IF F 80 DISK 

1400 FQPRINT 0 F 132 PRINTER 

1500 ITGTICF NS 80 

1600 I 1 80 RCVFLD 

1700 IDBFILE NS 80 

1800 I 1 80 DBDATA 

1900 I+ 
2000 I+ 
2100 IFEEDBK DS 
2200 I 38 45 FMTNM 
2300 1 273 282 PGMDEV 
2400 I 401 404 MAJMIN 
2500 I 401 402 MAJCOD 
2600 I 403 404 MINCOD 
2700 CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KK KK IK KKK ERE RIEREKE KEK 
2800 Cx 


2900 Cx THIS PROGRAM ISSUES THE READ OPERATION TO THE PROGRAM DEVICE 
3000 Cx TO RECEIVE RECORDS FROM THE SOURCE PROGRAM UNTIL THE CHANGE 
3100 Cx DIRECTION INDICATION IS RECEIVED. EACH RECORD RECEIVED IS 
3200 Cx PRINTED TO THE PRINT FILE. 


3400 Cx IF AN ERROR OCCURS, AN ERROR MESSAGE IS PRINTED AND THE 
3500 Cx JOB IS ENDED. 


*NOOPTIMIZE 


LAST 
UPDATE 


10/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
0/16/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
10/16/87 
10/16/87 
03/20/89 


Figure 11-12 (Part 1 of 4). Target Program Example — RTFBAT (System-Supplied Formats) 
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PAGE 
LINE 


PROGRAM 
ID 


CRRA RAR K KKK KKK KKK KKK ERK K EKER KKK KKK KKK KKK KKK KKK KKK ERIK EKER EKER ER 
em 3 | 

c RECDTA TAG 

c READ TGTICF 98 

c MAJCOD —-CABGT'@3! NOTOKR ERROR? 

c MAJCOD —CABEQ'@3! CHKTRN NO DATA ? 

c EXCPTPTREC 

c CHKTRN TAG 

c MINCOD — CABNE'@0! RECDTA RCVTRNRND ? 
CRRA KKK K KKK KKK KI KKK KKK KK KK KKK IK KKK KKK KKK KIKI KKK KERRI 


Cx 
Cx WHEN A RCVTRNRND INDICATION IS RECEIVED, THE PROGRAM STARTS 
Cx SENDING RECORDS TO THE SOURCE PROGRAM. RECORDS ARE SENT UNTIL 
C* THE END OF FILE IS REACHED ON THE DATABASE FILE. AT THIS TIME 
Cx A DETACH REQUEST IS SENT TO THE SOURCE PROGRAM. 


5200 Cx 

F300 Cx mR RR KR RK KIRK KR KR KR KIKI K KIRK KKK IKARIA KIRK IK KIKI KKK I KIA KIA KICK 
5400 cx fy 

5500 C SENDTA TAG 

5600 C READ DBFILE 98 

5700 C 98 EXSR ENDSES SEND DETACH 
5800 C EOFPSW IFNE '1' 

5900 C EXSR WCFRTN 

6000 C GOTO SENDTA SEND DATA 
6100 C END 

6200 Cen RIG III III III ICICI ICICI IIIA AR I I 


Cx 
C* WHEN THE END OF FILE IS REACHED, AN EOJ MESSAGE IS 
Cx PRINTED, AND CONTROL GOES TO END. 

Cx 


CRRA KARR KK KKK KKK KI KKK KK KK KKK KKK KKK IKK KKK KKK KKK KK EKER ERK KKK RRK 


c« 

C EXCPTOKEND 

C GOTO END 

CRAKEAR RIK KKK KK KI KKK KI KKK I KKK KKK IKK KIA KIKI KK IK IKK IK KICK, 
Cx 

C* WHEN AN I/0 OPERATION ERROR IS DETECTED, AN ABNORMAL 

C* TERMINATION MESSAGE IS PRINTED AND THE PROGRAM ENDS. 

Cx 


CRRA KARR KK KKK KKK KKK KKK KKK KKK KKK KKK IK KK IK KKK KKK KKK EKER ERK KKK 


c+ 

C NOTOKR TAG 

C EXCPTNOTOK 

CRRA KKK KKK KKK KKK KKK KE KEK KKK KKK KKK KKK KKK KKK KKK KKK KEKE KEKE KK KARR 
C* 

C* | WHEN PROCESSING IS FINISHED, THE LAST RECORD SWITCH IS SET 
C* AND THE PROGRAM IS ENDED. 


Cx 

CK AK RIK RIK KIRK KKK KKK IK KI IKI K KKK KKK IKI AKIRA RIKKI KIRK. 
c* 

C END TAG 

C SETON LR 

C RETRN 

CK RAK RIK RIK KIKI KR KI KKK KKK KIA KIRK IKK KKK IKI IK IKI AKI KIKI RK. 
Cx 

Cx THIS SUBROUTINE IS CALLED TO SEND DATA TO THE SOURCE PROGRAM. 


Cx IF A SESSION ERROR OCCURS, AN ABNORMAL TERMINATION MESSAGE IS 
Cx PRINTED, THE LR SWITCH IS SET, AND THE JOB IS ENDED. 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KK KKK KEKE KKK KARR 


BOO1 
001 
001 

E001 
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03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/16/87 
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c* B 

C WCFRTN BEGSR 

C EXCPTSNDATA 

Cc MAJCOD CABGT'03' NOTOKR ERROR? 
¢ ENDSR 

CRRA KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIRKE RE KERR KKK 
C* 

C* THIS SUBROUTINE IS CALLED AT END OF FILE TO SEND AN 

C* INDICATION TO THE LOCAL SYSTEM THAT TRANSMISSION IS ENDED. 
C* THE END OF FILE SWITCH IS SET TO END THE JOB. 

C* 

CRRA KARR KK KKK KKK KKK KKK KKK KKK KKK KKK IK KK KK IKI K KKK EKER ERR KKK 
c* By 

C ENDSES BEGSR 

Cc MOVE '1' *IN30 ACTV DETACH 
C MOVE '1' EOFPSW 1 

C EXCPTENDREC SEND DETACH 
C MAJCOD CABGT'03' NOTOKR ERROR? 
C ENDSR 

CRRA KKK KK KKK KKK KKK KKK KEK KKK KKK KK KKK KK KK IK KKK KKK KKK IRE RIE RE RE KERR 
OQPRINT E 1 PTREC 

0 RCVFLD 80 

0 El OKEND 

0 21 'RTFBAT HAS COMPLETED ' 
0 30 'NORMALLY.' 

0 El NOTOK 

0 21 'RTFBAT HAS COMPLETED ' 
0 32 'ABNORMALLY.' 

0 MAJCOD 37 

0 38 '/' 

0 MINCOD 40 

0 49 'FORMAT: ' 

0 FMTNM 60 

0 69 'DEVICE:' 

0 PGMDEV 80 

OTGTICF E SNDATA 

0 K8 '$$SENDNI' 

0 4 '0080' 

0 DBDATA 84 

0 E ENDREC 

0 K8 '$$SENDET' 

0 4 'Q000' 


13801 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 


x**x**e** END OF SO 
Additional Diagn 


* 7089 1100 RPG PROVIDES SEPARATE 
* 7086 1300 RPG PROVIDES BLOCK OR 
Cross Re 
File and Record References: 
FILE/RCD DEV/RCD 
02 DBFILE DISK 1300D 1 
03 QPRINT PRINTER 1400D 11 
01 TGTICF WORKSTN 1100D 1 
$$SENDET 13700 
$$SENDNI 13300 
Field References: 
FIELD ATTR REFERENCES (M 
*IN30 A(1) 11100M 
CHKTRN TAG 4200 4400D 
DBDATA A(80) 1800D 13500 
END TAG 7000 8700D 
ENDREC EXCPT 11300 13600 
ENDSES BEGSR 5700 11000D 
EOFPSW A(1) 5800 11200D 
FEEDBK DS(404) 1100 2100D 


FMTNM A(8) 2200D 12900 


URCE kk kK RK 

ostic Messages 
INDICATOR AREA FOR FILE TGTICF. 
UNBLOCK SUPPORT FOR FILE DBFILE. 


ference 


REFERENCES (D=DEFINED) 


700 5600 
700 11900 12200 13801 
500 4000 13200 13600 


=MODIFIED D=DEFINED) 
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MAJCOD A(2) 2500D 4100 4200 10000 12500 
* 7031 MAJMIN A(4) 2400D 

MINCOD A(2) 2600D 4500 12700 

NOTO EXCPT 7900 12200 

NOTOKR TAG 4100 7800D 10000 11400 

OKEND EXCPT 6900 900 

PGMDEV A(10) 2300D 13100 

PTREC EXCPT 4300 700 

RCVFLD A(80) 1600D 11800 

RECDTA TAG 3900D 4500 

SENDTA TAG 5500D 6000 

SNDATA EXCPT 9900 13200 

WCFRTN BEGSR 5900 9800D 

'00' LITERAL 4500 

‘93! LITERAL 4100 4200 10000 11400 

‘\! LITERAL 5800 11100 11200 
Indicator References: 

INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 

*IN 11100M 

LR 8800M 

OA 400D 13801 

30 11100M 
* 7031 80 500M 1700M 

98 4000M 5600M 5700 


END OF CROSS 
Message 


* QRG6103 Severity: 00 Number: 1 


REFERENCE 


Summary 


Kk KKK 


Message... . : No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 2 
Message... .: The Name or indicator is not referenced. 
* QRG7086 Severity: 00 Number: 1 
Message . . .. : The RPG handles blocking function for file. 


INFDS contents updated only when blocks of data transferred. 


* QRG7089 Severity: 00 Number: 1 
Message... . : The RPG provides Separate-Indicator area for 
file. 
e**e*** END OF MESSAGE SUMMARY * * * * * 
Final Summary 


Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


5 5 0 0 0 0 0 
Program Source Totals: 
Records: eee ae te ee He se HE 1388 
Specifications ......: 67 
Table Records .......: O 
GOMMENtS ae eee eh ew et AD 


PRM has been called. 


Program RTFBAT is placed in library ICFLIB. 00 highest Error-Severity-Code. 


xx*e** END OF COMPILATION 


xk KK * 


Figure 11-12 (Part 4 of 4). Target Program Example — RTFBAT (System-Supplied Formats) 


Multiple-Session Inquiry (Example Il) 


This example illustrates an interactive inquiry application that 
communicates with multiple ICF sessions. A source AS/400 
system program accepts inquiries from a display device and 
sends a request to one of four AS/400 systems. The source 
program communicates with the display device through a 
display file, and with the four remote systems through a 
single ICF file. 


The purpose of this example is to show multiple sessions 
from a single ICF file. The source program communicates 
with four sessions. From the viewpoint of each of the four 
target programs, the requester is the only session. There- 
fore, the target programs do not require any unique logic to 
support the multiple-session source. 


Both the source program and the target program are 
described. The same target program is evoked in each of 
the four separate remote systems. Therefore, only one 
target program is shown in the programming example. 
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Transaction Flow of the Multiple-Session Inquiry 
(Example Il): The program shown in Figure 11-13 is 
started from a display station. Both the display and the ICF 
files are opened. CIWS00 is the *REQUESTER device, and 
is acquired when the display file opens. CIWSO0 is acquired 
because DEV(*REQUESTER) was specified when the 
display file was created. Since the ICF file was created with 
ACQPGMDEV(*NONE), no ICF devices are acquired during 
open processing. 


Display 


Station 


Remote AS/400 System 


Display File 
CIWS00 


Open 


Remote AS/400 System 


Open 
i ICFOO 


Program 


ICFO1 


ICF02 


ICFO3 
ICF File 


R te AS/400 System 
Local AS/400 System oe 


Remote AS/400 System 


RSLS199-4 


Figure 11-13. Program Starts at Display Station 
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All other program devices must be explicitly acquired by the 
program, as shown in Figure 11-14. 


Display 


Station 


Remote AS/400 System 


Display File 
CIWS00 


Remote AS/400 System 


ICFOO 


Program ACQ 


> ICF01 


ACQ 
ICFO2 

ACQ 
ICFO3 
ICF File 


Remote AS/400 System 
Local AS/400 System : 


Remote AS/400 System 


RSLS651-4 


Figure 11-14. Program Devices Explicitly Acquired 
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All target programs are started with an evoke, as shown in 


Figure 11-15. 
Display 
Station 
Remote AS/400 System 
ICF Program Database 
>>| . 
File File 
Display File 
CIWSO0O 
Remote AS/400 System 
Write Evoke 
a 1 ICFOO 
rogram ‘ 
9 Write Evoke ICF Program Database 
ICFO1 >| ‘ F 
File File 
Write Evoke 
| ICFO2 
Write Evoke 
-—__—*} KS F03 
ICF File 
Remote AS/400 System 
Local AS/400 System 
ICF Program Database 
>| 
File File 
Remote AS/400 System 
ICF Program Database 
>| 
File File 


Figure 11-15. Evoke Starts Target Programs 
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rodca 


RSLS652-4 


The source program uses a specific program device name. 
Each target program uses an ICF file with a program device 


name that is associated with the requester. The target 


program's only session is the one used to communicate with 
the source program. The ICF file is implicitly opened by the 


RPG/400 language support when the target program is 


Display 


Station 


Write 


Program 


[> *> CIWSOoOo 


Display File 


started. Since the file was created with the requesting 
program device specified on the ACQPGMDEV parameter, 
the requesting program device is acquired with the implicit 
open. The main menu is written to the display station on the 
local system and the program waits for a request from the 
display station, as shown in Figure 11-16. 


Remote AS/400 System 


ICF 


File 


Program Database 


File 


Remote AS/400 System 


ICFOO 


ICFO1 


ICFO2 


ICFOS 


ICF File 


Local AS/400 System 


Figure 11-16. Main Menu Written to Display Station 


ICF 
File 


Program Database 


File 


Remote AS/400 System 


ICF 


File 


Remote AS/400 System 


ICF 
File 


Program Database 


File 


Program Database 
File 


RSLS653-5 
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The source program sends an inquiry request to one of the 
remote systems based on the request made from the display 
station, as shown in Figure 11-17. 


Remote AS/400 System 


Program 


Display File 


File 


Program 


Database 


File 


Remote AS/400 System 


ICF 


CIWSOO 
ICFOO 
Write 
with 
ja EE 
ICFO1 
Invite 
ICFO2 
ICFOS 
ICF File 


Local AS/400 System 


File 


Read 


Program 


Database 


File 


Remote AS/400 System 


File 


Program 


Database 


File 


Remote AS/400 System 


ICF 


File 


Program 


Database 


File 


ooad 


Figure 11-17. Program Sends Inquiry Request to Remote System 
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RSLs654-4 


The target program responds to the inquiry by sending a 


reply, as shown in Figure 11-18. 


Display 


Station 


Remote AS/400 System 


Program Read 


Display File 


CIWS00 


ICFOO 


= 


ICFO1 +} 


ICF02 


ICFO3 


ICF File 


Local AS/400 System 


Figure 11-18. Target Program Sends a Reply 


ICF Program Database 

File File 
Remote AS/400 System 

ICF Write | Program | Read | Database 

File . File 
Remote AS/400 System 

ICF Program Database 

File File 
Remote AS/400 System 

ICF Program Database 

File File 


mood 


RSLS655-4 
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The program sends a detach request and ends the session 
when command function key 1 is pressed (while the main 
inquiry menu is present), as shown in Figure 11-19. 


Display 


Station 


Remote AS/400 System 


ICF Program Database 
File File 
Display File 
CIWS00 
Remote AS/400 System 
Bearers ICFOO 
pate Write Detach i ICF Read | Program Database 
ICFO1 File ; File 
ICFO2 
ICFO3 
ICF File 
Local AS/400 System Remote AS/400 System 
ICF Program Database 
|| File File 
Remote AS/400 System 
ICF Program Database 
File File 


oaaod 


Figure 11-19. Program Ends the Session 
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RSLS656-5 


Source Program Multiple-Session Inquiry (Example 
Il): The following describes a source program multiple- 
session inquiry. 


Program Files: The RPG/400 multiple-session source 
program uses the following files: 


CMNFIL 
A ICF file used to send records to and receive 
records from the target program. 


DSPFIL 
A display file used to enter requests to be sent to 
the target program. 


QPRINT 
A printer file used to print error messages resulting 
from communications errors. 


DDS Source: The DDS for the ICF file (CMNFIL) is illus- 
trated below. 
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SOURCE FILE. ...... QICFPUB/ICFLIB 


MEMBER ......... CMNFIL 
SEQNBR# iF die cttiant 2 sete O ie dthice e Adele Daa ctherer Oc aine bined: hi cere ethene Oe ww eter Oo Gh bee Q 
100 10/06/87 
200 10/06/87 
300 [RR KKR KK EK EKA EKER EK ERE KEK KEK ERE KER KER ERE KER ERK ER ER ER ERE RR ER ER ERE EK 10/14/87 
400 Ax * 10/14/87 
500 Ax ICF FILE * 10/14/87 
600 Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 10/14/87 
700 Ax * 10/14/87 
800 [ERK RK RRR R RRR ER RRR ERE R ERR RRR RRR KERR KERR ER ERE KERR ERR RRR RRR RRERR RE 10/14/87 
900 A INDARA 10/07/87 
1000 A R ITMRSP 10/06/87 
1100 A RECID(1 'I') 10/06/87 
1200 A RECITM 1 10/06/87 
1300 A ITEMNO 6 0 10/13/87 
1400 A DESC 30 10/06/87 
1500 A QTYLST 7 0 10/06/87 
1600 A QTYOH 7 0 10/06/87 
1700 A QTYOO 7 0 10/06/87 
1800 A QTYBO 7 0 10/06/87 
1900 A UNITQ 2 10/06/87 
2000 A PRO1 A 2 10/06/87 
2100 A PRO5 7 0 10/06/87 
2200 A UFRT 5 2 10/06/87 
2300 A SLSTM 9 2 10/06/87 
2400 A SLSTY 11 2 10/06/87 
2500 A CSTTM 9 2 10/06/87 
2600 A CSTTY ll 2 10/06/87 
2700 A PRO 5 2 10/06/87 
2800 A LOS 9 2 10/06/87 
2900 A FILL1 56 10/06/87 
3000 A R DTLRSP 10/06/87 
3100 A RECID(1 'C') 10/06/87 
3200 A RCVTRNRND (90) 10/06/87 
3300 A RECCUS 1 10/06/87 
3400 A CUSTNO 6 0 10/13/87 
3500 A DNAME 30 10/06/87 
3600 A DLSTOR 6 0 10/06/87 
3700 A DSLSTM 9 0 10/06/87 
3800 A DSPMO1 9 0 10/06/87 
3900 A DSPMO2 9 0 10/06/87 
4000 A DSPMO3 9 0 10/06/87 
4100 A DSTTYD 11 0 10/06/87 
4200 A IDEPT 3 0 10/06/87 
4300 A FILL2 57 10/06/87 
4400 A R DETACH 10/06/87 
4500 A DETACH 10/06/87 
4600 A R EOS 10/06/87 
4700 A EOS 10/06/87 
4800 A R EVKREQ 10/06/87 
4900 A EVOKE (&LIB/&PGMID) 10/12/87 
5000 A PGMID 10A P 10/06/87 
5100 A LIB 10A_ P 10/06/87 
5200 A R ITMREQ 10/06/87 
5300 A INVITE 10/06/87 
5400 A ITEMNO 6 0 10/13/87 
5500 A R DTLREQ 10/06/87 
5600 A INVITE 10/06/87 
5700 A CUSTNO 6 0 10/13/87 


**** END OF SOURCE *** * 
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The DDS source file for the display file (DSPFIL) is shown 


below. 


000100871007 
000200871007 
000300871007 
000400871007 
000500871007 
000600871007 
000700871008 
000800871008 
000900871007 
001000871007 
001100871007 
001200871007 
001300871007 
001400871007 
001500871007 
001600871007 
001700871007 
001800871008 
001900871008 
002000871007 
002100871013 
002200871008 
002300871008 
002400871008 
002500871008 
002600871007 
002700871008 
002800871007 
002900871007 
003000871007 
003100871008 
003200871008 
003300871007 
003400871007 
003500871007 
003600871007 
003700871007 
003800871007 
003900871007 
004000890321 
004100871008 
004200871008 
004300871007 
004400871008 
004500871007 
004600871008 
004700871007 
004800871008 
004900871013 
005000871008 
005100871008 
005200871008 
005300871008 
005400871008 
005500871007 
005600871007 
005700871007 
005800871007 
005900871007 
006000871007 
006100871007 
006200871007 
006300871007 
006400871007 
006500871007 
006600871007 
006700871007 
006800871007 
006900871007 
007000871007 
007100871007 
007200871007 
007300871007 
007400871007 
007500871008 
007600871008 
007700871008 
007800871008 


007900871008 
008000871008 
008100871008 
008200871007 
008300871007 
008400871007 
008500871007 
008600871007 
008700871007 
008800871007 
008900871007 
009000871007 
009100871007 
009200871007 
009300871007 
009400871007 
009500871007 
009600871008 
009700871008 
009800871008 
009900871007 
010000871008 
010100871007 
010200871007 
010300871007 
010400871007 
010500871007 


[iti pddaai niin SSSI IGS IID SSGSSII SEIS ISI IASI 


Ax * 
Ax DISPLAY FILE * 
Ax USED IN SOURCE MULTIPLE SESSION PROGRAM * 
Ax * 


[lpia niin SSSI DISCS SSGSSII IIIS GEE IDI IASI 


Ax BEGINNING MENU 


[Vereeeeeeeerrererrs.y 


A 

A 

A R CIMENU 

A 

A 

A 

A 

A 

A OPTION IN I 
A 

A R DTLMNU 

A 

A CUSTNO 6N O1 
A 

A 

Ax 


[tpiddadeaniinninnisniaciiiinininininiok 


Ax CUSTOMER INQUIRY SCREEN 


[poididasciariniinninininniaciaiininininiiek 


A R DTLSCR 

A 

A 

A 

A CUSTN 6N 
A DEPT 3N 0 
A DLSTR 6N 0 
A DSLSM ON 0 
A DSPM1 ON 0 
A DSPM2 ON 0 
A DSPM3 ON O 
A DSTYD 11N 0 
A CNAME 5 

A 

A 

Ax 


[ipiddaceiinnininininianiiiniiniink 


Ax ITEM INQUIRY SCREEN 


[ipiddaaciinninnnnsacidiininiink 


A R ITMMNU 

A 

A ITEMNO 6N O1 
A 

A 


[ioidiseiciciinninninniaciiiininiink 
Ax ITEM DISPLAY 


[ipidseciaciiniininniniaciiiininiink 


A R ITMSC2 

A 

A 

A DSC 30 

A 

A QAVAIL 7N 0 
A 

A QTYH 7N 0 
A 

A Qryo 7N 0 
A 

A QTYB 7N 0 
A 

A UNT 2 

A 

A PRI 7Y 2 
A 

A PRS 7Y 0 
A 

A UFR 5Y 2 
A 

A 

A 

A 


[tpi ddascaribinninnsnciiiininininiiak 
Ax ITEM ADDITIONAL DISPLAY 


[ipiddddcianiiinninisisacciaiiininininiiek 


A R ITMSC3 

A 

A 

A SLSM oY 2 
A 

A SLSY 1lyY 2 
A 

A CSTM oY 2 
A 

A CSTY 1ly 2 
A 

A PROFIT 5Y 2 
A 

A LOSTS oY 2 
A 

A 


[ipiddaciadiiniinnninianiiiiininink 
Ax — TIMOUT SCREEN 


[ioidideciinnininninaniniininiink 


A R TIMOUT 

A 

A 

A TIMRSP sa | 


DSPSIZ(*DS3) 
CFO1(99) CFO2(98) CFO3(97) 
TEXT('MENU FOR INQUIRY') 

1 34' INQUIRY MENU' 

3. 1'Select one of the following:' 

4 3'1. Item inquiry' 

5 3'2. Customer inquiry! 

11 1'Option:' 

11 QVALUES('1' '2') 

19 5DFT('CMD KEY 1 - END ') 
TEXT('CUSTOMER INQUIRY SCREEN 1') 

2 2DFT('ENTER CUSTOMER') 

2 20 

19 5DFT('CMD KEY 1 - END ') 

19 23DFT(' 2 - MAIN MENU ') 


TEXT('CUSTOMER INQUIRY SCR. #2') 
3DFT('CUST DPT LAST ORD & THIS 
$MTH1 &MTH2 S$MTH3 
THIS YTD NAME') 


74 
5DFT('CMD KEY 1 - END ') 
23DFT(' 2 - MAIN MENU ') 


TEXT('ITEM INQUIRY SCREEN ONE') 
2 2DFT('ENTER ITEM NUMBER') 
2 20 
19 5DFT('CMD KEY 1 - END ') 
19 23DFT(' 2 - MAIN MENU ') 


TEXT('ITEM INQUIRY SCREEN TWO') 
OVERLAY 

2DFT('DESC-') 

8 


2DFT('QUANTITY AVAILABLE') 
25 

11DFT('ON HAND') 

25 


11DFT('ON ORDER') 
25 

11DFT('BACK ORDER') 
25 


2DFT('UNIT OF MEASURE') 
9 30 

10 2DFT('PRICE PER UNIT') 
10 24EDTCDE(3) 

11 8DFT('QUANTITY') 

11 25EDTCDE(3) 

12 8DFT('FREIGHT') 

12 26EDTCDE(3) 

13 32DFT('MORE... ') 

19 5DFT('CMD KEY 1 - END ') 
19 23DFT(' 2 - MAIN MENU ') 
19 40DFT(' 3 - ITEM MENU ') 


TEXT('ITEM INQUIRY SCREEN 3 ') 
OVERLAY 
5 2DFT('SALES MONTH') 
5 16EDTCDE(1) 
6 8DFT('Y-T-D') 
6 14EDTCDE(1) 
7 2DFT('COSTS MONTH') 
7 16EDTCDE(1) 
8 8DFT('Y-T-D') 
8 14EDTCDE(1) 
9 2DFT('PROFIT PCT') 
9 22EDTCDE(1) 
10 2DFT('LOST SALES') 
10 16EDTCDE(1) 
19 5DFT('CMD KEY 1 - END ') 
19 23DFT(' 2 - MAIN MENU ') 


TEXT('TIME OUT SCREEN') 
OVERLAY 

20 2DFT('REMOTE SYSTEM TIMED OUT. ENTER 
1 TO TRY AGAIN OR 2 TO END.') 

20 61 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/CMNFIL) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(CMNFIL) ACQPGMDEV(*NONE) MAXPGMDEV(4) WAITRCD(30) 
TEXT("SOURCE ICF FILE FOR MULTIPLE SESSION PROGRAM") 


The commands needed to define the four program device 
entries are: 
OVRICFDEVE PGMDEV(ICFOQ) RMTLOCNAME (CHICAGO) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICFQ1) RMTLOCNAME (NEWYORK) FMTSLT(*RECID) 
OVRICFDEVE PGMDEV(ICF02) RMTLOCNAME(DETROIT) FMTSLT(*RECID) 


OVRICFDEVE PGMDEV(ICF03) RMTLOCNAME (MADISON) FMTSLT(*RECID) 


Program Explanation: The following explains the structure 
of the program examples illustrated in Figure 11-20 on 

page 11-38 and in Figure 11-21 on page 11-52. The ICF 
file used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
data and system-supplied formats. The reference numbers 
in the explanation below correspond to the numbers in the 
following program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the way the user- 
defined formats and the system-supplied formats are used. 
All output operations to the ICF file in the first example are 
done using the WRITE statement. All output operations in 
the ICF file in the second example using system-supplied 
formats are done using the EXCPT statement. 


Differences between the first and second example are 
described as notes in each of the following descriptions 
where necessary. 


The file specifications define the ICF file (CMNFIL) and 
the display file (DSPFIL) used in the program. 


CMNMNFIL is the ICF file used to send records to and 
receive records from each of the four target programs. 


DSPFIL is the display file used to receive user’s 
requests and to report the information received based 
on the request. 


The files used in the program are opened at the begin- 
ning of the RPG/400 cycle. 


Note: In the program using system-supplied formats, 
the input records for CMNFIL are explicitly coded in the 
program since CMNFIL is now treated as a program- 
described file. The system-supplied file, QICDMF, can 
be used instead of CMNFIL. To use QICDMF, specify 
QICDMF in the file specification, or use an OVRICFF 
command to change the file name from CMNFIL to 
QICDMF. 


The continuation lines on the file specification define 
the following: 


¢ The data structure names, IOFB and IODS, used 
for the feedback area (INFDS) for CMNFIL and 
DSPFIL respectively. 
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¢ The number of program devices that can be 
attached to the files (four for CMNFIL). 


e The program device name in CMID field to which it 
issues the I/O operation. 


The file information data structure (IOFB) is provided to 
receive the I/O feedback area following an ICF file I/O 
operation. 


For the display file, the file information data structure 
(IODS) is used by the program to determine the record 
format used for the last display file I/O operation. The 
field name referenced in the program is RECID, found 
in positions 261 through 268 of the feedback area. 


The four ICF program devices used by the program are 
explicitly acquired. 


The work station is implicitly acquired when the 
DSPFIL file opens. 


Also, the evoke requests are issued to the remote 
systems by the subroutine at Pq. 


When control returns from [RJ the main menu (record 
format CIMENU) is written to the work station. 


A read operation is issued to the display program 
device and the program waits for an input request from 
the user. When a record is returned, the last record 
format used (as specified in the RECID field in the I/O 
feedback area) is checked. The program branches to 
the appropriate routine according to the value in 
RECID. 


The request entered by the user from the main menu 
(CIMENU) is checked. If indicator 99 is set to 1, indi- 
cating that the operator pressed function key 1, the 
four transactions and sessions end and the program 
ends. If the operator entered option 1, the program 
writes the item inquiry menu (ITMMNU) to the work 
station and returns to QJ. 


If the option is not 1, the customer inquiry menu 
(DTLMNU) is written to the work station and control is 
passed to Qj. 


The item number requested by the user from the Item 
Inquiry Screen (record format ITMMNU) is processed 
here. If function key 1 is pressed (indicator 99), control 
passes to [fRJ, the four transactions and sessions are 
ended, and the program ends. If function key 2 is 
pressed, the inquiry request is canceled, the main 
menu (CIMENU) is written to the work station, and the 
program returns to J. 


The item number read from the work station is checked 
for value range. If the range is from 0 to 399999, then 
the request is sent to the target program on program 
device ICFO1. 


If the range is from 400000 to 699999, then the 
request is sent to the target program on program 
device ICF02. 
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If the range is from 700000 to 899999, then the 
request is sent to the target program on program 
device ICFO3. 


The request is sent to the appropriate target program 
by writing data to the program device using format 
ITMREQ. The INVITE keyword is specified as part of 
the ITMREQ format to give the target program permis- 
sion to send. 


A read-from-invited-program-devices operation is 
issued to the invited program device to receive the 
response to the inquiry. The operation is interpreted 
as a read-from-invited-program-devices because the 
program device name field (CMID) is blank. Indicator 
89 is set on after I/O operation, if the operation does 
not complete. Subroutine gets control, and further 
checks are made. 


The return codes are checked after every I/O request. 
If there are any errors, control is passed to fF. 


The program returns to [j. 


Note: In the program using system-supplied formats, 
the $$SEND format is used instead of the user-defined 
ITMREQ format. Also, the EXCPT statement is used 
instead of the WRITE statement. 


The information received from the target program is 
processed. If the returned item number is 0 or less, 
the request is not valid, a new item inquiry menu 
(ITMMNU) is written to the work station, and control 
goes to Qj. 


The program then performs the calculations to set the 
quantity fields and writes the result to the requesting 
work station using record format ITMSC2. 


The program then returns to Qj. 


This section processes the user requests for additional 
information (record format ITMSC2). If function key 2 
(indicator 98) was pressed, the main menu (record 
format CIMENU) writes to the work station and control 
goes to J. 


If function key 2 was pressed (as indicated by indicator 
98), the profit and loss figures are calculated. Those 
values are then written to the work station using format 
ITMSC3 (item inquiry work station 3). The program 
then returns to EJ. If function key 1 (indicator 99) was 
pressed, control goes to §F4. 


If function key 3 (indicator 97) was pressed, the Item 
Inquiry Menu (ITMMNU) is written to the work station 
and the program returns to Qj. 


This section processes requests read from the cus- 
tomer menu (DTLMNU). If function key 2 (indicator 98) 
was pressed, the main menu (CIMENU) is written to 
the work station and the program returns to QJ. If 
function key 1 (indicator 99) was pressed, control goes 


io FA. 


The customer inquiry request is send to the target 
program by writing data to the program device (ICFO0) 


using format DTLREQ. The INVITE keyword is speci- 
fied as part of the DLTREQ format to give the target 
program permission to send. 


A read operation is issued to the invited program 
device to receive the response to the inquiry. This is 
accomplished by blanking out CMI/D. Indicator 88 is 
set on if the I/O operation did not complete. 


The return codes are checked after every I/O request. 
If there are any errors, control is passed to —4. 


Note: In the program using system-supplied formats, 
the $$SEND format is used instead of the user-defined 
DTLREQ format. Also, the EXCPT operation is used 
instead of the WRITE operation. The READ operation 
is issued using ICF file CMNFIL in factor 2. 


The information supplied by the target program in 
response to a request for a customer detail is pro- 
cessed. If the customer number is 0 or less, the 
request is no valid and the main menu (record format 
CIMENU) is written to the work station. The program 
then returns to QJ. 


The detail information is written to the work station 
using record format DTLSCR. 


The program then returns to Qj. 


The return codes are checked after every I/O request 
to verify the success of the operation. 


Note: The READ operation is issued using file name 
CMNFIL in factor 2 in the program using system- 
supplied formats. 


Control is passed here if the customer detail record 
format (DLTSCR) is displayed. If function key 1 (indi- 
cator 99) was pressed, control goes to FR. If function 
key 2 (indicator 98) was pressed, the main menu 
(CIMENU) is written to the work station and control is 
returned to QJ. 


If the record format name is not found on a read opera- 
tion, an error message prints. If an error occurs on 
any ICF operation, control is passed here and an error 


message is printed containing the program device and 
error that occurred. 


For each of the four sessions, the transaction is ended 
by issuing a detach request to the appropriate program 
device using format DETACH, and the session is 
ended by the release operation. The last record indi- 
cator is turned on to end the program. The ICF file is 
implicitly closed at the end of the RPG/400 cycle. 


This subroutine builds the evoke requests to send to 
the remote systems. Because the DDS keyword for 
the record format only specifies the field identifiers with 
the record, this code moves the literal value 
RTDMULCL to the field PGMID, and ICFLIB to the field 
LIB. 


When the program start request is received at the 
remote system, ICFLIB is searched for RTDMULCL 
and that program is then started. RTDMULCL is a CL 
program that contains the following: 


ADDLIBLE ICFLIB 
CALL ICFLIB/RTDMUL 


Note: In the program using system-supplied formats, 
the library and program (ICFLIB/RTFMULCL) are spec- 
ified as part of the $$EVOKNI format. RTFMULCL is a 
CL program that contains the following: 


ADDLIBLE ICFLIB 
CALL ICFLIB/RTFMUL 


This subroutine is called when the read operation to 
the program device does not complete. The indication 
that the timer has ended is checked (RC=0310), and, if 
it is set, a message displays to the user. The message 
asks whether to try the read operation again, or to end 
the job. In this example, the time interval is specified 


at HQ. 


This subroutine is called for I/O operation errors that 
are not handled by subroutine QJ. It checks whether 
the program device is already acquired when an 
acquire operation is requested, and, if it is, the second 
acquire is ignored. Otherwise the program ends. 
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Compiler... ........ 2... 2 IBM AS/400 RPG/400 
Command Options: 


Program ..... 2... 2... 2  ICFLIB/RSDMUL 
Source file .......... :  ICFLIB/QICFPUB 
Source member ......... :  *PGM 

Text not available for message RXT0073 file QRPGMSG. 
Generation options. ...... :  *NOLIST *NOXREF *NOATR *NODUMP 
Source listing indentation... :  ¥*NONE 
SAA flagging. ......... : + *NOFLAG 
Generation severity level ...: 9 
Print: Til@.. «4.4% GA ee ef OAEIBL/QSYSPRT 
Replace program ........:  *YES 
Target release... ...... : +  *CURRENT 
User profile. .........: ¥*USER 
Authority ........... 3:  *LIBCRTAUT 
TEX 6 cee ite, ee ere et we we a 3 RSRCMBRTXT, 
Phase trace ..........: = *NO 
Intermediate text dump... .. :  *NONE 
Snap dump ........... :  *NONE 
Codelist..........2..: = *NONE 
Ignore decimal data error ...:  ¥*NO 

Actual Program Source: 
Member... ...... 6... :  RSDMUL 
FATS cos ae ee, dian ve se ae ee 2) SQTCFPUB 
ETDPAaNY:. ose Sis cee ey a ek EOI CELIB 
Last Change ..........: 10/03/90 14:46:07 
Description .......... : RPG Multi-Session example w/DDS (source) 


Source Listing 


100 H&K AKA K KKK KKK KKK K KK ERK KKK KKK KEK ERK RRR KEKE KEK ERK KERR KEE KER ERK RRR 
200 H* * 
300 H* THIS PROGRAM ASSIGNS FOUR SESSIONS AS FOLLOWS: * 
400 H* "ICFOO' TO INQUIRE ABOUT A CUSTOMER ACCOUNT BEFORE AN * 
500 H* ORDER IS PROCESSED. * 
600 H* "ICFO1' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 
700 H* BEING ORDERED (ITEM 000001 THRU 399999). * 
800 H* "ICFO2' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 
900 H* BEING ORDERED (ITEM 400000 THRU 699999). * 
1000 H* "ICFO3' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM * 
1100 H* BEING ORDERED (ITEM 700000 THRU 999999). * 
1200 H* A DISPLAY DEVICE IS USED TO ENTER THE REQUEST (USING A * 
1300 H* CUSTOMER AND AN ITEM MENU) THAT IS SENT TO THE REMOTE * 
1400 H* SYSTEM. * 
1500 H* * 
1600 H&K KKK KAKA KKK KERR KK ERK KKK KERR KKK ERK KKK ERE KEK ERK KERR EKER EK ERE RRR REREER 


*NOOPTIMIZE 
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4900 
5000 


FRR KAKA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KKK IKARIA REE ERE 


Fe 
Fx FILE SPECIFICATIONS 
Fe 
Fx CMNFIL : ICF FILE USED TO SEND A REQUEST TO ONE 
Fx OF FOUR DIFFERENT TARGET PROGRAMS. MULTIPLE 
Fx SESSIONS ARE ACTIVE CONCURRENTLY. 
Fe 
Fx DSPFIL : DISPLAY FILE USED TO ENTER A REQUEST TO BE 
Fx SENT TO A REMOTE SYSTEM. 
Fe 
Fx THE FOLLOWING INFORMATION IS SPECIFIED AS PART OF THE 
Fx FILE SPECIFICATION: 
Fx INFDS : I/0 FEEDBACK AREA 
Fx NUM SPECIFIES THE MAXIMUM NUMBER OF 
Fx PROGRAM DEVICES THAT CAN BE ATTACHED 
Fx TO THIS FILE. A VALUE OF 4 IS 
Fx SPECIFIED FOR THE ICF FILE. 
Fx THIS DEFINES THE FILE AS A 
Fx MULTIPLE DEVICE FILE. 
Fx ID 10 CHARACTER PROGRAM DEVICE NAME 
Fx FIELD WHICH SPECIFIES WHICH PROGRAM 
Fx DEVICE TO DIRECT THE OPERATION. 
Fe 
Fe 
FR KAR KAR KKK RR KKK KKK RIKKI KK IKK I KKK IKI KIA KKK IK KIRK IKARIA KIA K 
-H 
H 
FCMNFIL CF E WORKSTN 
F KINFDS IOFB 
F KINFSR *PSSR 
F KNUM 4 
F KID CMID 
RECORD FORMAT(S): LIBRARY ICFLIB FILE CMNFIL. 

EXTERNAL FORMAT ITMRSP RPG NAME ITMRSP 

EXTERNAL FORMAT DTLRSP RPG NAME DTLRSP 

EXTERNAL FORMAT DETACH RPG NAME DETACH 

EXTERNAL FORMAT EOS RPG NAME EOS 

EXTERNAL FORMAT EVKREQ RPG NAME EVKREQ 

EXTERNAL FORMAT ITMREQ RPG NAME ITMREQ 

EXTERNAL FORMAT DTLREQ RPG NAME DTLREQ 
FDSPFIL CF E WORKSTN 
F KINFDS IODS 
RECORD FORMAT(S): LIBRARY ICFLIB FILE DSPFIL. 

EXTERNAL FORMAT CIMENU RPG NAME CIMENU 

EXTERNAL FORMAT DTLMNU RPG NAME DTLMNU 

EXTERNAL FORMAT DTLSCR RPG NAME DTLSCR 

EXTERNAL FORMAT ITMMNU RPG NAME ITMMNU 

EXTERNAL FORMAT ITMSC2 RPG NAME ITMSC2 

EXTERNAL FORMAT ITMSC3 RPG NAME ITMSC3 

EXTERNAL FORMAT TIMOUT RPG NAME TIMOUT 
FQPRINT OO F 32 PRINTER 
[RK KKK KKK RK RRA KKK KK KIRK RK KIKI AK IKK KKK IKI AKI KIA KIKI KIA KIA 
Ix 
Ix INPUT SPECIFICATIONS 
Ix 
Ix IODS REDEFINES THE I/O FEEDBACK AREA OF THE DISPLAY 
Ix FILE. THIS AREA CONTAINS THE NAME OF THE LAST 
Ix RECORD PROCESSED. THIS FIELD IS CALLED RECID. 
Ix IOFB REDEFINES THE 1/0 FEEDBACK AREA FOR THE ICF 
Ix FILE. 
Ix 
ee 


KKK 


10/13/87 
10/13/87 


Figure 11-20 (Part 2 of 14). Source Program Example — RSDMUL (User-Defined Formats) 
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6300 
AQ00000 
AQ00001 
AQ00002 
AQ00003 
A000004 
AQ00005 
AQ00006 
AQ00007 
AQ00008 
AQ00009 
A000010 
AQ00011 
AQ00012 
A000013 
A000014 
AQ00015 
AQ00016 
AQ00017 
A000018 
B000000 
B000001 
BO00002 
B000003 
BO00004 
BO00005 
B000006 
B000007 
B000008 
B000009 
B000010 
B000011 
C000000 
DO00G00 
E000000 
F000000 
FQ0000 
G000000 
G00000 
H000000 
H000000 
HOG000 
HOG0002 
H000003 
H000004 
1000000 
1000000 
100000 
1000002 
1000003 
1000004 
J000000 
J000000 
J00000 
J000002 
J000003 
K000000 
K000000 
K000001 
Ko00002 
K000003 
Ko00004 
L000000 
L000000 
L000001 
Lo00002 
L000003 
M000000 
MQ00000 
MO00001 
M000002 


Ix 


10/13/87 


INPUT FIELDS FOR RECORD ITMRSP FILE CMNFIL FORMAT ITMRSP. 


1 
2 


96 1 
107 1 
116 1 
127 1 
132 1 
141 1 


RECITM 
70ITEMNO 


O62SLSTY 
152CSTTM 
262CSTTY 
312PRO 
402L0S 
96 FILL1 


INPUT FIELDS FOR RECORD DTLRSP FILE CMNFIL FORMAT DTLRSP. 


INPUT 
INPUT 
INPUT 
INPUT 


INPUT 


INPUT 


INPUT 


INPUT 


INPUT 


INPUT 


INPUT 


FIELDS FOR RECORD DETACH FILE CMNFIL FORMAT DETACH. 
FIELDS FOR RECORD EOS FILE CMNFIL FORMAT EOS. 
FIELDS FOR RECORD EVKREQ FILE CMNFIL FORMAT EVKREQ. 


FIELDS FOR RECORD ITMREQ 
FIELDS FOR RECORD DTLREQ 


FIELDS FOR RECORD CIMENU 
MENU FOR INQUIRY 


FIELDS FOR RECORD DTLMNU 
CUSTOMER INQUIRY SCREEN 1 


FIELDS FOR RECORD DTLSCR 
CUSTOMER INQUIRY SCR. #2 


FIELDS FOR RECORD ITMMNU 
ITEM INQUIRY SCREEN ONE 


FIELDS FOR RECORD ITMSC2 
ITEM INQUIRY SCREEN TWO 


FIELDS FOR RECORD ITMSC3 
ITEM INQUIRY SCREEN 3 


FILE 


FILE 


FILE 


FILE 


FILE 


FILE 


FILE 


FILE 


CMNFIL 
1 

CMNFIL 
1 

DSPFIL 


4 
DSPFIL 


4 
DSPFIL 


3 

2 

1 
DSPFIL 


Pm Ww 


4 
DSPFIL 


3 

2 

1 
DSPFIL 


3 
2 


FORMAT ITMREQ. 
601TEMNO 
FORMAT DTLREQ. 
60CUSTNO 
FORMAT CIMENU. 


3 *IN97 

2 *IN98 

*IN99 

4 OPTION 
FORMAT DTLMNU. 


3 *IN97 

2 *IN98 

*IN99 
9OCUSTNO 
FORMAT DTLSCR. 


3 *IN97 
2 *IN98 
*IN99 
FORMAT ITMMNU. 


3 *IN97 

2 *IN98 

*IN99 
9OITEMNO 
FORMAT ITMSC2. 


3 *IN97 
2 *IN98 
*IN99 
FORMAT ITMSC3. 


3 *IN97 
2 *IN98 
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MQ00003 
N000000 
No00000 
N0G0001 


1 1 *IN99 


INPUT FIELDS FOR RECORD TIMOUT FILE DSPFIL FORMAT TIMOUT. 
TIME OUT SCREEN 


IIODS DS 
I 
I 
I 
IIOFB DS 
I 
I 
I 
I 
I 
I 
I 
I 
I 


Cx 


*INQ7 
*IN98 
*IN99 
TIMRSP 


NS 
PrPNWw 


240 FILLO1 
261 268 RECID 
271 415 FILLO2 


*ROUTINE LOC 

*STATUS ERR 

240 FILLO3 
38 45 FMTNM 
273 282 CMID 

401 404 MAJMIN 
401 402 MAJCOD 
403 404 MINCOD 
261 268 RECID2 
271 415 FILLO4 


Cx CALCULATION SPECIFICATIONS 


Cx THE DISPLAY PROGRAM DEVICE IS IMPLICITLY ACQUIRED WHEN THE 


Cx FILE IS OPENED. 


Cx ALL OF THE ICF PROGRAM DEVICES ARE EXPLICITLY ACQUIRED. 


Cx EACH OF THE FOUR TARGET PROGRAMS ARE EVOKED TO ESTABLISH 
Cx TRANSACTIONS WITH THE REMOTE SYSTEMS. 


Cx THE MAIN INQUIRY MENU (CIMENU) IS WRITTEN TO THE USER'S 


CRRA KKK K KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KIKI KKK EKER KKK R IR 


TAG 

"ACQ. CMNFIL 1ST SESSION 
"ACQ) CMNFIL 2ND SESSION 
"ACQ. CMNFIL 3RD SESSION 
"ACQ) CMNFIL 4TH SESSION 
MOVEL'ICFOO 'CMID 1ST PROGRAM 
EXSR EVKSR CALL EVOKE 
MOVEL'ICFO1 ‘CMID 2ND PROGRAM 
EXSR EVKSR CALL EVOKE 
MOVEL'ICFO2 'CMID 3RD PROGRAM 
EXSR EVKSR CALL EVOKE 
MOVEL'ICFO3 = 'CMID 4TH PROGRAM 
EXSR EVKSR CALL EVOKE 
TAG 

WRITECIMENU 


CRRA KARR KK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KIKI KKK EKER ER KKK ARE 


Cx 

Cx DISPLAY. 

Cx 

*H 

C ENTRY 
C "ICFOO 
C "ICFO1 
C "ICFO2 
C "ICFO3 
C 

C 

C 

C 

C 

C 

C 

C 

C MAIN 

C 

Cx 

Cx 

Cx 


DETERMINE USER'S REQUEST 


Cx A READ TO THE DISPLAY DEVICE IS ISSUED TO RECEIVE THE USER'S 
Cx REQUEST. THE TYPE OF REQUEST MADE IS BASED ON THE DISPLAY 

Cx FORMAT CURRENTLY ON THE SCREEN. THE RECORD FORMAT NAME IS 
Cx EXTRACTED FROM THE I/0 FEEDBACK AREA AND IS USED TO DETER- 
Cx MINE WHAT ACTION SHOULD BE TAKEN NEXT. 


CRRA KKK K KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KER RRR KKK 


10/13/87 


10/13/87 


Figure 11-20 (Part 4 of 14). Source Program Example — RSDMUL (User-Defined Formats) 
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QAaAaanaanaan 


c 


READRQ TAG 
SETOF 8889 
READ DSPFIL 

RECID CABEQ'CIMENU ‘MENU 

RECID CABEQ'ITMMNU 'ITMIN 

RECID CABEQ'ITMSC2 'ITMRTN 

RECID CABEQ'ITMSC3 'ITMRTN 

RECID CABEQ'DTLMNU 'DTLIN 

RECID CABEQ'DTLSCR 'DTLRTN 
WRITECIMENU 
GOTO READRQ 


TIMEOUT IND 
87 
MAIN MENU? 
ITEM MENU? 
ITM SCR? 

ITM SCR? 
DETAIL SCR? 
CUST SCR? 
MAIN MENU IF 
THERE IS ERR 


CRRA KKK KKK KKK KKK KKK KKK KKK KK KKK KK IK IKK KKK KKK KKK IKK KKK EKER ERK KARR 


*H 


MAIN MENU 


THE MAIN MENU IS READ TO DETERMINE THE REQUEST 
BY THE USER. IF CMD 1 (*IN99) IS PRESSED, THE 
IS ENDED. IF OPTION = 1, AN ITEM INQUIRY MENU 
TO THE SCREEN. IF OPTION = 2, A CUSTOMER INQU 
WRITTEN TO THE SCREEN. 


MENU TAG 
*IN99 CABEQ'1' END 
OPTION  IFEQ ‘1! 
WRITEITMMNU 
ELSE 
WRITEDTLMNU 
END 
GOTO READRQ 


ENTERED 
PROGRAM 

IS WRITTEN 
IRY MENU IS 


JOB ENDS 


ITEM MENU 


CUST MENU 


CARA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERK KARR 


ITEM INQUIRY 


THE ITEM NUMBER REQUESTED BY THE USER ON THE I 
SCREEN IS CHECKED. THIS IS DETERMINED BY THE 
RECORD FORMAT BEING PROCESSED - IN THIS CASE I 


IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS EN 
IS PRESSED, THE ITEM INQUIRY REQUEST IS CANCEL 
MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 


IF AN ITEM NUMBER IS ENTERED, A ITEM INQUIRY R 
SENT TO THE APPROPRIATE REMOTE SYSTEM. THE RE 


IF AN ERROR OCCURS, THE ERROR IS PRINTED AND T 
IS ENDED. 


IS SELECTED BASED ON THE ITEM NUMBER REQUESTED. 


TEM INQUIRY 
DISPLAY 
TMMNU. 


DED. IF CMD 2 
ED, AND THE 


EQUEST IS 
MOTE SYSTEM 


HE JOB 


CRRA KKK K KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK K IK IKK KKK KKK ERK 


‘G 


AaAaanananannannanaanaa 


OQ 


ITMIN TAG 
IN99 CABEQ'1' END 
*IN98 IFEQ '1' 
WRITECIMENU 

GOTO READRQ 

END 
ITEMNO  CABLE399999 ~_—X CFL 
ITEMNO  CABLE699999 _—XICF2 
ITEMNO — CABLE899999—XICF03 
XICFOl TAG 


* 


MOVEL'ICFO1 ‘CMID 
GOTO XITMIN 
XICFO2 TAG 
MOVEL'ICFO2 'CMID 
GOTO XITMIN 


XICFOQ3 TAG 
MOVEL'ICFO3 'CMID 
XITMIN TAG 


WRITEITMREQ 
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EXIT ON CMD3 


MAIN MENU 


INQ W/INVITE 
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19400 
19500 
19600 
19700 
19800 
19900 
20000 
20100 
20200 
20300 
20400 
20500 
20600 
20700 
20800 
20900 
21000 
21100 
21200 
21300 
21400 
21500 
21600 
21700 
21800 
21900 
22000 
22100 
22200 
22300 
22400 
22500 
22600 
22700 
22800 
22900 
23000 
23100 
23200 
23300 
23400 
23500 
23600 
23700 
23800 
23900 
24000 
24100 
24200 
24300 
24400 
24500 
24600 
24700 
24800 
24900 
25000 
25100 
25200 
25300 
25400 
25500 
25600 
25700 
25800 
25900 


89 


AaQaanaaa 


c 


Cxx**K 


CxK**K 


a7 


QAaAaanananannannanaanaa 


Cc 


Cxw*KK 


CxKxeK 


MAJCOD CABGE'04' ERROR ERROR RTN 
TRY89 TAG 

SETOF 89 

MOVEL' "CMID 

READ CMNFIL 8910RECV ITM INFO 

EXSR ERRCHK CHCK ERR INFO 
MAJMIN CABGE' 0300' ITMIN NODATATRYAGN 
MAJCOD CABGE'04' ERROR ERROR RTN 
RECID2 CABNE'ITMRSP' RECERR PRINT MSG 


HK IK KK IKK II KK KI KK IKK IIR III KKK IIR AIC I IIR III II RII IK AIK 
PROCESS ITEM INFORMATION 


THE ITEM RECORD RECEIVED FROM THE TARGET PROGRAM AND THE 
INFORMATION ABOUT THE ITEM IS PROCESSED AND DISPLAYED. 

IF ITEMNO IS @ OR LESS, IT IS AN INVALID REQUEST AND A FRESH 
ITEM MENU IS WRITTEN TO THE SCREEN. IF THE REQUEST IS 
VALID, VALUES ARE CALCULATED BASED ON THE INFORMATION 
RECEIVED. 


KHKKK KKK KKK KKK KKK KKK KKK ERK EKER KK KEK KKK KKK KKK KEKE RERRKERERRERER 
ITMOUT TAG 
ITEMNO IFLE 000000 
WRITEITMMNU ITEM MENU 
GOTO READRQ READ DISPLY 
ELSE 
Z-ADDO QAVAIL 70 QTY AVAIL. 


ADD QTYOH QAVAIL 
SUB QTYOO QAVAIL 
ADD QTYBO QAVAIL 


MOVELDESC DSC 
MOVE QTYOO QTYo 
MOVE QTYOH QTYH 
MOVE QTYBO QTYB 
MOVE UNITQ UNT 
MOVE PRO1 PRI 
MOVE PROS PR5 
MOVE UFRT UFR 
WRITEITMSC2 DSP DETAIL 
GOTO READRQ 
KEKKKEKKEKKKR KEKE KR EKER EKER ERK ERR EKER EERE KRKRERR EKER ERR ERKEEKREKRKEKERE 
ADDITIONAL ITEM INFORMATION 
ADDITIONAL ITEM INFORMATION IS PROCESSED AND THE RESULT 
DISPLAYED ON THE SCREEN WHEN A RESPONSE IS READ FROM THE 


DISPLAY WITH AN ITEM SCREEN RECORD FORMAT. 
IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS ENDED. 


IF CMD 2 (*IN98) IS PRESSED, THE ITEM INQUIRY IS ENDED, AND 
THE MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 


IF CMD 3 (*IN97) IS PRESSED, THE ITEM INQUIRY MENU IS 
WRITTEN ON THE SCREEN. 


IF 'ENTER' IS PRESSED WHILE SCREEN 2 FOR ITEM REQUESTED IS 
URRENTLY DISPLAYED, MORE INFORMATION IS CALCULATED AND 
ISPLAYED. 


oo 


IF 'ENTER' IS PRESSED WHILE SCREEN 3 FOR ITEM REQUESTED IS 
CURRENTLY DISPLAYED, THEN THE ITEM INQUIRY MENU IS WRITTEN 
TO THE SCREEN. 


SII III OI III IOI IO III IOI II I III IIR FI II IK 


3 0/13/87 0Q 


23 0/13/87 
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26000 
26100 
26200 
26300 
26400 
26500 
26600 
26700 
26800 
26900 
27000 
27100 
27200 
27300 
27400 
27500 
27600 
27700 
27800 
27900 
28000 
28100 
28200 
28300 
28400 
28500 
28600 
28700 
28800 
28900 
29000 
29100 
29200 
29300 
29400 
29500 
29600 
29700 
29800 
29900 
30000 
30100 
30200 
30300 
30400 
30500 
30600 
30700 
30800 
30900 
31000 
31100 
31200 
31300 
31400 
31500 
31600 
31700 
31800 
31900 
32000 
32100 
32200 
32300 
32400 
32500 
32600 
32700 
32800 


ITMRTN 
*IN9O 
*IN98 


*IN97 
RECID 


RECID 


SLSTM 


SLSTM 
PROFM 
QTYLST 


N46 


AaAaanannnnannannnnanananaaanaana 


c 


TAG 
CABEQ'1' 
IFEQ '1' 
RITECIMENU 


FEQ ‘1! 
FEQ 'ITMSC2 
RITEITMMNU 


FEQ 'ITMSC3 
RITEITMMNU 


OMP 0 


GOTO READRQ 


END 


PROFM = =92 
PROFM 


PROFM 
LOSTS 
SLSM 
SLSY 
CSTM 
PROFIT 
CSTY 


JOB ENDS 


MAIN MENU 


CMD 3 ? 
ITM SCR 2 ? 
YES, THEN ITS 
ITEM MENU 


ITM SCR 3 ? 
YES, THEN ITS 
ITEM MENU 


PROF MONTH 
46 


PROF PCT 
LOST SALES 


DET ITM INF 


CARA RAK K KKK KKK KKK KEK KK KKK KKK KKK IKK KKK KKK KKK KKK KKK ERE KKK IRI 


CUSTOMER INQUIRY 


Cx THE REQUEST FROM THE CUSTOMER INQUIRY MENU IS PROCESSED. 


Cx IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS ENDED. 


Cx IF CMD 2 (*IN98) IS PRESSED, THE CUSTOMER INQUIRY IS ENDED, 


Cx AND THE MAIN MENU (CIMENU) IS 


WRITTEN TO THE SCREEN. 


Cx IF A CUSTOMER NUMBER IS ENTERED, THE CUSTOMER INQUIRY 


Cx REQUEST IS SENT TO THE REMOTE 


SYSTEM. 


Cx A READ TO THE ICF PROGRAM DEVICE IS ISSUED TO RECEIVE THE 


Cx INFORMATION FROM THE TARGET P 


ROGRAM. 


Cx IF AN ERROR OCCURS, THE ERROR IS PRINTED AND THE JOB IS 


CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KK IKK KKK KKK KIKI K IKKE KERR KKK ARIK 


Cx 

Cx ENDED. 

Cx 

*O 

C DTLIN 

C *IN99 

C *IN98 

C 

C 

C 

C EVDTL 

C 

C 

C MAJCOD 
C TRY88 

C 

C 

C 

C 88 

C MAJMIN 
C MAJCOD 
C RECID2 
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ICF Programming 


TAG 
CABEQ'1' 
IFEQ '1' 


WRITECIMENU 
GOTO READRQ 
END 
TAG 
MOVEL' ICF00 
WRITEDTLREQ 
CABGE'04' 
TAG 
SETOF 

MOVEL' 

READ CMNFIL 
EXSR ERRCHK 
CABGE'0300' 
CABGE'04! 
CABNE' DTLRSP! 


END 


"CMID 


ERROR 


"CMID 


EVDTL 
ERROR 
RECERR 


JOB ENDS 


MAIN MENU 


CUST INQ 
ERROR RTN 


88 


8810RCV CUS INF 
CHECK ERR 
NODATATRYAGN 
ERROR RTN 
PRINT MSG 


2.3. 


. Source Program Example — RSDMUL (User-Defined Formats) 


V4R1 


32900 
33000 
33100 
33200 
33300 
33400 
33500 
33600 
33700 
33800 
33900 
34000 
34100 
34200 
34300 
34400 
34500 
34600 
34700 
34800 
34900 
35000 
35100 
35200 
35300 
35400 
35500 
35600 
35700 
35800 
35900 
36000 
36100 
36200 
36300 
36400 
36500 
36600 
36700 
36800 
36900 
37000 
37100 
37200 
37300 
37400 
37500 
37600 
37700 
37800 
37900 
38000 
38100 
38200 
38300 
38400 
38500 
38600 
38700 
38800 
38900 
39000 
39100 
39200 
39300 
39400 
39500 
39600 
39700 


CRRA KKK K KKK KKK KKK KK EKER KKK KKK KKK KKK KKK KKK KIKI KIKI KEKE RK RKK KARR 


Cc 


Cc 


* 


* 


PROCESS CUSTOMER INFORMATION 


THE CUSTOMER DATA RECEIVED FROM THE TARGET PROGRAM IS 
PROCESSED. IF CUSTOMER NUMBER IS ZERO OR LESS, IT IS AN 
INVALID REQUEST AND THE MAIN MENU IS WRITTEN TO THE SCREEN. 


WHEN THE RCVTRNRND INDICATOR(IN9O) IS RECEIVED, THE CUSTOMER 
INFORMATION IS WRITTEN TO THE SCREEN. 


IF DURING THE READ 


OPERATION AN ERROR IS RECEIVED, CONTROL GOES TO THE ERROR 


ROUTINE TO END THE JOB. 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK RIKKI KIKI KIRKE KERR KKK IK 


QAaAaananananaanaana 


c 


* 


DTOUT TAG 

CUSTNO —_-IFEQ 000000 
SETOF 
WRITECIMENU 
GOTO READRQ 
END 
MOVE CUSTNO 
MOVELDNAME 
MOVE DLSTOR 
MOVE DSLSTM 
MOVE DSPMO1 
MOVE DSPMO2 
MOVE DSTTYD 
MOVE IDEPT 
WRITEDTLSCR 
GOTO READRQ 


CUSTN 
CNAME 
DLSTR 
DSLSM 
DSPM1 
DSPM2 
DSTYD 
DEPT 


66 
MAIN MENU 


BLD CUS SCR 


CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK RIK IKI KKK KKK KERR IRR 


THIS ROUTINE HANDLES THE USER'S REQUEST FOLLOWING THE 
DISPLAY OF THE CUSTOMER INFORMATION. 
THE JOB, CMD KEY 2 WILL DISPLAY THE MAIN MENU, AND "ENTER" 


WILL BRING UP THE CUSTOMER INQUIRY MENU. 


CMD KEY 1 WILL END 


CARA KARR KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KK KKK EKER KR KKK IRR 


* 


DTLRTN ‘TAG 

*IN99 CABEQ'1 

*IN98 IFEQ '1' 
WRITECIMENU 
GOTO READRQ 
END 
WRITEDTLMNU 
GOTO READRQ 


END 


JOB ENDS 


MAIN MENU 


CUSTOMER INQ 


CCR KARA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IKKE KERRIER 


WHEN AN 1/0 OPERATION ERROR IS DETECTED, A MESSAGE IS 
PRINTED AND THE TRANSACTION AND SESSION ARE ENDED FOR EACH 


OF THE REMOTE SYSTEMS. 


CRRA RAK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KIKI KKK KERR KKK ARR 


AAQAAaAaNaAaNAAAAAOA 


OQ 


* 


RECERR TAG 
EXCPTRECER 
GOTO END 

ERROR TAG 
EXCPTMMERR 

END TAG 
MOVEL' ICF0O 
WRITEDETACH 
MOVEL' ICFO1 
WRITEDETACH 
MOVEL' ICFO2 
WRITEDETACH 
MOVEL' ICF03 
WRITEDETACH 


"CMID 


"CMID 


"CMID 


"CMID 


WRONG RECID 
END PROGRAM 


DET 1ST TRN 


DET 2ND TRN 


DET 3RD TRN 


DET 4TH TRN 


10/13/87 


10/13/87 
10/13/87 
10/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 
0/13/87 
0/13/87 

001 0/13/87 
Bo02 0/13/87 
3 002 0/13/87 
002 0/13/87 
002 0/13/87 
E002 0/13/87 
001 0/13/87 
001 08/08/89 
001 0/13/87 
001 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 
0/13/87 
0/13/87 

001 0/13/87 
001 0/13/87 
Bo02 0/13/87 
002 0/13/87 
002 0/13/87 
E002 0/13/87 
001 0/13/87 
001 0/13/87 
0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
0/13/87 
0/13/87 
0/13/87 

00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
00 0/13/87 
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C ABORT TAG 

C "ICFOO = ='REL =CMNFIL 86 REL 1ST SES 
C "ICFO1 = 'REL) = CMNFIL 86 REL 2ND SES 
Cc "ICFO2 = 'REL) «=CMNFIL 86 REL 3RD SES 
C "ICFO3 ‘REL = CMNFIL 86 REL 4TH SES 
C FORCE TAG 

C SETON LR 

C RETRN 

C END 

CHR KKK AKA K KKK KKK IKK KKK KR ER ERE KIKI KI KKK KERIKERI KIKI IK IER IR IERIE. 
Cx 

Cx THIS SUBROUTINE IS CALLED TO EVOKE THE TARGET PROGRAM. THE 
Cx SAME TARGET PROGRAM (ICFLIB/RTDMULCL) IS EVOKED AT FOUR 


Cx DIFFERENT REMOTE SYSTEMS. 
Cx WHICH SESSION SHOULD BE EVOKED. 


THE PROGRAM DEVICE IDENTIFIES 
THE PROGRAM DEVICE WAS 


Cx SPECIFIED IN CMID PRIOR TO CALLING THIS ROUTINE. 


Cx 

CK RK RK RIK RIA KR KIRK IK KKK KAKI KKK IKI KIKI KIKI KK IRI I KIA KIA 
13 

Cc EVKSR BEGSR 

Cc MOVE *BLANK PGMID BLANK QUT 

C MOVE *BLANK LIB BLANK QUT 

C MOVEL' RTDMULCL' PGMID PROGR NAME 
C MOVEL'ICFLIB ‘LIB LIBRARY 

C WRITEEVKREQ 

C MAJCOD CABGE'04' END TO END PGM 
C ENDSR 

CK KR KK RIK RIK KIKI RK IKI K KIA KAKA KIKI KIKI KAKI KIKI KIA KIA 
Cx 

Cx THIS SUBROUTINE IS CALLED TO PERFORM FURTHER CHECKS ON FILE 
Cx ERRORS RESULTING FROM THE READ OPERATION ISSUED TO THE PRO- 
Cx GRAM DEVICE. THIS ROUTINE CHECKS FOR THE TIME OUT INDICATION. 
Cx IF THERE IS A TIME OUT, A MESSAGE IS SENT TO THE USER'S 

Cx DISPLAY SCREEN REQUESTING ACTION, OTHERWISE PROGRAM ENDS. 
Cx 

CRRA KR KK RIK KR KR KIRK IK KK KIKI KIKI KIKI RIKKI IKI RIKKI RIKKI IKI K 
* 

Cc ERRCHK BEGSR 

Cc MAJMIN IFEQ '0310' TIMER EXPD? 
C CHKAGN TAG 

Cc WRITETIMOUT DISPLAY MSG 
C READ DSPFIL 86READ REPLY 
C 88 TIMRSP CABEQ'1' TRY88 CUST INQUIR 
Cc 89 TIMRSP CABEQ'1' TRY89 ITEM INQUIR 
C TIMRSP IFEQ '2' END PROGRAM 
Cc RITEEOS END SESSION 
C GOTO FORCE END PROGRAM 
C END 

C GOTO CHKAGN ASK AGAIN 

C END 

C GOTO ERROR ABEND 

C ENDSR 


CRRA KARR KKK KKK KKK KEK RK KKK KKK KKK KKK KKK AKIRA KKK KKK KIRK K KIRK 


Cx THIS IS THE PROG 


RAM ERROR SUBROUTINE THAT RECEIVES CONTROL 


WHEN AN ERROR OCCURS AFTER AN I/O OPERATION IS ISSUED TO 
THE PROGRAM DEVICE AND THERE IS A NON-ZERO VALUE IN THE RPG 


Cx STATUS FIELD (ERR). 


Cx THAT RELATE TO I 
Cx IS ALREADY ACQUI 


THIS ROUTINE CHECKS FOR STATUS VALUES 
CF OPERATIONS. IF THE PROGRAM DEVICE 
RED, THE ERROR IS IGNORED, OTHERWISE, THE 


Cx PROGRAM IS TERMINATED. 


DEFAULT 
ALREADY ACQ? 
JOB ENDS 


Cx 

CHK KRHA KA KR KK KKK IKK KKK KR KKK ERIK IKI KKK KIKI KIKI I AIK IR IRIE R IRA. 
‘i 

C *PSSR BEGSR 

C MOVE ' "RETURN 6 

C ERR CABEQO1285 ENDPSR 

C MOVE '*CANCL' RETURN 

C ENDPSR ENDSRRETURN 


BACK TO MAIN 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK IKI KKK KKK KERR KKK RRR 
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NNN DY 


0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/16/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/14/87 
0/14/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/03/90 
03/20/89 
03/20/89 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/13/87 


X000000 
X000000 
X000001 
X000002 
X000003 
X000004 
X000005 
X000006 
X000007 
xX000008 
X000009 
Y000000 
Y000000 
Y000001 
Yoo0002 
Y000003 
Y000004 
Y000005 
Y000006 
Z000000 
Z000000 


* 7089 


OQPRINT E 1 MMERR 
0 21 ‘COMMUNICATION ERROR. ! 
0 34 'MAJOR/MINOR: ' 
0 MAJCOD 37 
0 38 '/! 
0 MINCOD 40 
0 49 ‘FORMAT: ' 
0 FMTNM 60 
0 69 'PGMDEV:' 
0 CMID 80 
0 El RECER 
0 20 'UNMATCH RECD FORMAT! 
0 31 '-JOB ENDS.! 
0 MAJCOD 37 
0 38 '/! 
0 MINCOD 40 
0 49 ‘FORMAT: ' 
0 RECID2 60 
0 69 'PGMDEV:' 
0 CMID 80 
48701 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 
OUTPUT FIELDS FOR RECORD DETACH FILE CMNFIL FORMAT DETACH. 
OUTPUT FIELDS FOR RECORD EOS FILE CMNFIL FORMAT EOS. 
OUTPUT FIELDS FOR RECORD EVKREQ FILE CMNFIL FORMAT EVKREQ. 
PGMID 10 CHAR 10 
LIB 20 CHAR 10 
OUTPUT FIELDS FOR RECORD ITMREQ FILE CMNFIL FORMAT ITMREQ. 
ITEMNO 6 ZONE 6,0 
OUTPUT FIELDS FOR RECORD DTLREQ FILE CMNFIL FORMAT DTLREQ. 
CUSTNO 6 ZONE 6,0 
OUTPUT FIELDS FOR RECORD CIMENU FILE DSPFIL FORMAT CIMENU. 
MENU FOR INQUIRY 
OUTPUT FIELDS FOR RECORD DTLMNU FILE DSPFIL FORMAT DTLMNU. 
CUSTOMER INQUIRY SCREEN 1 
OUTPUT FIELDS FOR RECORD DTLSCR FILE DSPFIL FORMAT DTLSCR. 
CUSTOMER INQUIRY SCR. #2 
CUSTN 6 CHAR 6 
DEPT 9 ZONE 3,0 
DLSTR 15 ZONE 6,0 
DSLSM 24 ZONE 9,0 
DSPM1 33 ZONE 9,0 
DSPM2 42 ZONE 9,0 
DSPM3 51 ZONE 9,0 
DSTYD 62 ZONE 11,0 
CNAME 67 CHAR 5 
OUTPUT FIELDS FOR RECORD ITMMNU FILE DSPFIL FORMAT ITMMNU. 
ITEM INQUIRY SCREEN ONE 
OUTPUT FIELDS FOR RECORD ITMSC2 FILE DSPFIL FORMAT ITMSC2. 
ITEM INQUIRY SCREEN TWO 
DSC 30 CHAR 30 
QAVAIL 37 ZONE 7,0 
QTYH 44 ZONE 7,0 
QTYO 51 ZONE 7,0 
QTYB 58 ZONE 7,0 
UNT 60 CHAR 2 
PRI 67 ZONE 7,2 
PR5 74 ZONE 7,0 
UFR 79 ZONE 5,2 
OUTPUT FIELDS FOR RECORD ITMSC3 FILE DSPFIL FORMAT ITMSC3. 
ITEM INQUIRY SCREEN 3 
SLSM 9 ZONE 9,2 
SLSY 20 ZONE 11,2 
CSTM 29 ZONE 9,2 
CSTY 40 ZONE 11,2 
PROFIT 45 ZONE 5,2 
LOSTS 54 ZONE 9,2 
OUTPUT FIELDS FOR RECORD TIMOUT FILE DSPFIL FORMAT TIMOUT. 
TIME OUT SCREEN 


x eK KK 


Additional 


4400 


END 


OF 


Diag 


SOURCE 


nostic 


ke 


* 


Messages 
RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE CMNFIL. 


02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
02/24/89 
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Cross Reference 
File and Record References: 
FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 


01 CMNFIL WORKSTN 4400D 9700 9800 9900 10000 
19800 32400 39900 40000 40100 
40200 
DETACH 4400D C000000 39100 39300 39500 
39700 0000000 
DTLREQ 4400D G000000 31900 S000000 
DTLRSP 4400D BOQ0000 
EOS 4400D DOQ0000 44300 Pa00000 
EVKREQ 4400D E000000 42200 Q000000 
ITMREQ 4400D FOQ0000 9300 ROOQ000 
ITMRSP 4400D AQQ0000 
02 DSPFIL WORKSTN 4900D 12500 43900 
CIMENU 4900D HO00000 1000 13200 17800 
26400 31400 34600 37100 T000000 
DTLMNU 4900D 1000000 5100 37400 000000 
DTLSCR 4900D J000000 35700 Va00000 
ITMMNU 4900D K000000 4900 21800 26900 
27400 W000000 
ITMSC2 4900D LOQ0000 23300 X000000 
ITMSC3 4900D MOQ0000 28700 YO00000 
TIMOUT 4900D NOQ0000 43800 Z000000 
03 QPRINT PRINTER 5100D 46800 47800 48701 
Field References: 
FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 
*IN97 A(1) HQ00001 1000001 J000001 KO000001 LQ00001 
MO00001 NQQ0001 26700 
*IN98 A(1) HO00002 1000002 JOO0e02 KODR002 LOQ0002 
MO00002 NOQO002 17700 26300 31300 
37000 
*IN9O A(1) HQ00003 1000003 J000003 K000003 LQ00003 
MO00003 NOQ0003 14700 17600 26200 
31200 36900 
*PSSR BEGSR 4400 46200D 
* 7031 ABORT TAG 39800D 
CHKAGN TAG 43700D 44600 
CMID A(10) 7300D 10100M 10300M 10500M 10700M 
18500M 18800M 19100M 19700M 31800M 
32300M  39000M 39200M 39400M  39600M 
47700 48700 
CNAME A(5) 35000M VOQ0009D 
CSTM P(9,2) 28400M Y000003D 
CSTTM P(9,2) AQ0Q0014D 27700 28400 
CSTTY P(11,2) AQQ0015D 28600 
CSTY P(11,2) | 28600M Yoo0004D 
CUSTN A(6) 34900M VO00001D 
CUSTNO P(6,0) B000002Z2D GOO0DO01D 1000004D 34400 34900 
$000001D 
DEPT P(3,0) 35600M V0Q0002D 
DESC A(30) AQ00003D 22500 
DLSTOR P(6,0) BOQ0004D 35100 
DLSTR P(6,0) 35100M V000003D 
DNAME A(30) BQ00003D 35000 
DSC A(30) 22500M X000001D 
DSLSM P(9,0) 35200M VO00004D 
DSLSTM P(9,0) BOQ0005D 35200 
DSPMO1 P(9,0) BOQ0006D 35300 
DSPM02 P(9,0) BOQ0007D 35400 
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* 7031 


* 7031 


* 7031 


7031 
7031 
7031 
7031 
7031 
7031 


FF FF 


* 7031 


* 7031 
* 7031 


* 7031 


* 7031 


* 7031 


DSPMO3 


MAJCOD 


MAMIN 
MENU 
MINCOD 
MMERR 
OPTION 
PGMID 
PRO 
PROFIT 
PROFM 
PROL 
PROS 
PRI 
PRS 
QAVAIL 
QTYB 
QTYBO 
QTYH 
QTYLST 
QTYo 
QTYOH 
QTYo0 
READRQ 


RECCUS 
RECER 
RECERR 


P(9,0) 
P(9,0) 
P(9,0) 
P(9,0) 
P(11,0) 
P(11,0) 


P(6,0) 


TAG 


Figure 11-20 (Part 12 of 


BQ00008D 
35300M 
35400M 

V000007D 

BOG0009D 


7800D 
A000018D 
BQ00011D 
7200D 
40300D 
BQ00010D 
4900 
4400 
A000002D 
8300 
2700 
21600D 
2800 
41900M 
6900D 
A000017D 
28100M 
0900D 
7500D 
42300 
7400D 
2600 
7600D 
38800 
H000004D 
41800M 
A000016D 
28500M 
27700D 
A000009D 
A000010D 
23000M 
23100M 
22100D 
22800M 
A000007D 
22700M 
A000004D 
22600M 
AQ00005D 
A000006D 
12300D 
23400 
31500 
BQ00001D 
38500 
20200 


V000005D 
V000006D 


35500 
V000008D 

31100D 

36800D 


17600 
38900D 
46600D 


46400 
32500 
20100 


32600 
10400 


47500 
44400 
35600 
6400D 
6800D 
FQ00001D 
21700 
17500D 


12900 
42100M 


Y000006D 


19400 
47100 
20000 
14600D 
47300 
46800 
14800 
42000M 


Y000005D 
27800M 
23000 
23100 

X000007D 

X000008D 
22200M 

X000005D 
22400 

X000003D 
28100 

X000004D 
22200 
22300 
13300 
26500 
34700 


47800 
32800 


26200 
42300 


43500D 
32000 


10600 


ko00004D 
RQO0001D 
20000 


26100D 
Q000002D 


20100 
48100 
32600 


48300 


Q000001D 


28000 
28100 


22300M 


22800 


22700 
22600 
15300 
27000 
35800 


38400D 


31200 


32700 


10800 


18100 


32000 


43600 


28000M 


36900 


38700D 


41700D 


18200 


32700 


28500 


22400M X000002D 


17900 
27500 
37200 


21900 
28800 
37500 
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* 7031 


Indicator References: 
INDICATOR REFE 


* 7031 


* 7031 
* 7031 
7031 


* 
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RECID 


RECID2 
RECITM 
RETURN 
SLSM 
SLSTM 


"*CANCL' 
"CIMENU 
‘DTLMNU 
"DTLRSP' 
‘DTLSCR 
‘ICFLIB 
‘ICFOO 

‘ICFO1 

‘ICFO2 

‘ICFO3 

‘I TMMNU 
"I TMRSP ' 
‘I TMSC2 
‘I TMSC3 


"RTDMULCL" 


'0300' 
0310! 
104! 
4! 


899999 


*IN 


A(8) 6600D 
13000 
A(8) 7700D 
A(1)  A900001D 
A(6) 46300D 
P(9,2)  28200M 
P(9,2) AQQ0012D 
P(11,2) AQQ0013D 
P(11,2)  28300M 
A(1)  No00004D 
TAG 32100D 
TAG 19500D 
P(5,2)  23200M 
P(5,2) AQQ0011D 
A(2)  A900008D 
A(2) 22900M 
TAG 8100 
TAG 8200 
TAG 8300 
TAG 8600 
LITERAL 41800 
LITERAL 19700 
LITERAL 46300 
LITERAL 46500 
LITERAL 12600 
LITERAL 13000 
LITERAL 32800 
LITERAL 13100 
LITERAL 42100 
LITERAL 9700 
LITERAL 9800 
LITERAL 9900 
LITERAL 10000 
LITERAL 12700 
LITERAL 20200 
LITERAL 12800 
LITERAL 12900 
LITERAL 42000 
LITERAL 20000 
LITERAL 43600 
LITERAL 19400 
LITERAL 14700 
26300 
37000 
LITERAL 44200 
LITERAL 22100 
LITERAL 21700 
LITERAL 46400 
LITERAL 27800 
LITERAL 18100 
LITERAL 18200 
LITERAL 18300 
H000001 HO00002 
J000001 Jo00002 
000001 Looe002 
No0001 Noood2 
26200 26300 
37000 
40400M 
5100D 48701 
19800M  32400M 
27900M 28000 
34500M 
39900M  40000M 
12500M 
12400M  32200M 
12400M  19600M 
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12600 
13100 
20200 


46500M 
Y000001D 
27700 
28300 
Y000002D 
44000 
44000 
44100 
X000009D 
23200 
22900 
X000006D 
18400D 
18700D 
19000D 
18900 
41900 
32300 


10100 
10300 
10500 
10700 


26800 
27300 


32600 


20100 
14800 
26700 
44000 


27900 
34400 


1000003 
J000003 
LO00003 
N000003 

26700 


40100M 


32400M 
19800M 


12700 
26800 
32800 


46600 


27900 


44100 


19200D 


31800 
18500 
18800 
19100 


32000 
17600 
31200 
44100 


RENCES (M=MODIFIED D=DEFINED) 


1000001 
K000001 
MO00001 
14700 
31200 


40200M 


32500 
19900 


12800 
27300 
48500 


28000 


44200 


39000 
39200 
39400 
39600 


32700 
17700 
31300 


1000002 
ko00002 
MO00002 
17600 
31300 


43900M 


44000 
44100 


12900 


28200 


39900 
40000 
40100 
40200 


42300 
26200 
36900 


1000003 
K000003 
MQ00003 
17700 
36900 


x 7031 90 


oF HOG0001 1000001 J000001 KO000O1 LOGOOO1 MO00001 
NOG0001 26700 

98 HOG0002 1000002 JO000O2 KO0OOOZ LOGO0O2 MO0OOOZ 
Noo0002 17700 26300 31300 37000 

99 HO00003 1000003 J000003 KO00003 LOO0003 M0O0003 


N0G0003 14700 17600 26200 31200 36900 
eee *e* END OF CROSS REFERENCE ** * * * 


Message Summary 
* QRG6103 Severity: 00 Number: 1 


Message... . : No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 22 
Message... .: The Name or indicator is not referenced. 
* QRG7089 Severity: 00 Number: 1 

Message... . : The RPG provides Separate-Indicator area for 

file. 


xe ee * END OF MESSAGE SUMMARY ** * * * 


Final Summary 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


24 24 0 0 0 0 0 
Program Source Totals: 
Records: 02 a ahead se ch 487 
Specifications ......: 245 
Table Records. ......: O 
GomMENts © seca et we we 242 


PRM has been called. 


Program RSDMUL is placed in library ICFLIB. 00 highest Error-Severity-Code. 


ee ee * END OF COMPILATION ** * * * 
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COMPITE RS Marca cart he aaa ee IBM AS/400 RPG/400 
Command Options: 
PrOghalss cde seal ce. Ate, Seas Peete: fede ICFLIB/RSFMUL 
Source file .......... :  ICFLIB/QICFPUB 
Source member ......... :  *PGM 
Text not available for message RXT0073 file QRPGMSG. 
Generation options. ...... :  *NOLIST *NOXREF *NOATR *NODUMP 
Source listing indentation... :  ¥*NONE 
SAA flagging. ......... : + *NOFLAG 
Generation severity level ...: 9 
Print: Til@.. «4.4% GA ee ef OAEIBL/QSYSPRT 
Replace program ........:  *YES 
Target release... ...... : +  *CURRENT 
User profile. .........: ¥*USER 
Authority ........... 3:  *LIBCRTAUT 
TEX 6 cee ite, ee ere et we we a 3 RSRCMBRTXT, 
Phase trace ..........: = *NO 
Intermediate text dump... .. :  *NONE 
Snap dump ........... :  *NONE 
Codelist..........2..: = *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member... ...... 6... :  RSFMUL 
FATS cs ee, dae oe se ee ee, | AQTCEPUB 
EDDPAaNY:. os wise cee ey a ek EY SI CELIB 
Last Change ..........: 10/03/90 14:47:52 
Description .......... : RPG Multi-Session example w/$$FORMAT (source) 
Source Listing 
100 H&K KKK KAKA KKK KERR KK ERK KKK KKK KEK ERK RRR KEE KEK ERK EER KEE RERE RRR RREREER 
200 H* 
300 H* THIS PROGRAM ASSIGNS FOUR SESSIONS AS FOLLOWS: 
400 Hx "ICFOO' TO INQUIRE ABOUT A CUSTOMER ACCOUNT BEFORE AN 
500 Hx ORDER IS PROCESSED. 
600 H* ‘ICFO1' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM 
700 Hx BEING ORDERED (ITEM 000001 THRU 399999). 
800 H* "ICFO2' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM 
900 Hx BEING ORDERED (ITEM 400000 THRU 699999). 
1000 H* ‘ICFO3' TO INQUIRE ABOUT THE INVENTORY STATUS OF AN ITEM 
1100 H* BEING ORDERED (ITEM 700000 THRU 999999). 
1200 H* A DISPLAY DEVICE IS USED TO ENTER THE REQUEST ( USING A 
1300 H* CUSTOMER AND AN ITEM MENU) THAT IS SENT TO THE REMOTE 
1400 Hx SYSTEM. 
1500 H* 
1600 FARK KKK KKK KK KKK KERR KER KKK KKK KEKE ERK ERR KERR KER RK EKER KERR KEE REAR ERE 
1700 Fx 
1800 Fx FILE SPECIFICATIONS 
1900 Fx 
2000 Fx CMNFIL : ICF FILE USED TO SEND A REQUEST TO ONE 
2100 Fx OF FOUR DIFFERENT TARGET PROGRAMS. MULTIPLE 
2200 Fx SESSIONS ARE ACTIVE CONCURRENTLY. 
2300 Fx 
2400 Fx DSPFIL : DISPLAY FILE USED TO ENTER A REQUEST TO BE 
2500 Fx SENT TO A REMOTE SYSTEM. 
2600 Fx 


*NOOPTIMIZE 
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Fx THE FOLLOWING INFORMATION IS SPECIFIED AS PART OF THE 
Fx FILE SPECIFICATION: 
Fx INFDS : I/0 FEEDBACK AREA 
Fx NUM SPECIFIES THE MAXIMUM NUMBER OF PRO- 
Fx GRAM DEVICES THAT CAN BE ATTACHED T0 
Fx THIS FILE. A VALUE OF 4 IS SPECIFIED 
Fx FOR THE ICF FILE. THIS DEFINES 
Fx THE FILE AS A MULTIPLE DEVICE FILE. 
Fx ID : 10 CHARACTER PROGRAM DEVICE NAME FIELD 
Fx WHICH SPECIFIES WHICH PROGRAM DEVICE TO 
Fx DIRECT THE OPERATION. 
Fx ID : 10 CHARACTER PROGRAM DEVICE NAME 
Fx FIELD THAT SPECIFIES WHICH PROGRAM 
Fx DEVICE TO DIRECT THE OPERATION. 
Fe 
Fe 
FRR KAR KAR RAK IKK KR KAR KAR KAKI KKK KKK IK KK IKK KIKI IK KIKI KIKI A KIRK IK 
-H 
H 
FCMNFIL CF F 150 WORKSTN 
F KINFDS IOFB 
F KINFSR *PSSR 
F KNUM 4 
F KID CMID 
FDSPFIL CF E WORKSTN 
F KINFDS IODS 
RECORD FORMAT(S): LIBRARY ICFLIB FILE DSPFIL. 
EXTERNAL FORMAT CIMENU RPG NAME CIMENU 
EXTERNAL FORMAT DTLMNU RPG NAME DTLMNU 
EXTERNAL FORMAT DTLSCR RPG NAME DTLSCR 
EXTERNAL FORMAT ITMMNU RPG NAME ITMMNU 
EXTERNAL FORMAT ITMSC2 RPG NAME ITMSC2 
EXTERNAL FORMAT ITMSC3 RPG NAME ITMSC3 
EXTERNAL FORMAT TIMOUT RPG NAME TIMOUT 
FQPRINT OO F 132 PRINTER 


[RRR KKK KKK KEK KKK KKK KKK KKK KKK KKK KKK KKK RIKER KKK KKK AKIRA ARIK 


I* 


Ix INPUT SPECIFICATIONS 

I* 

I* IODS : REDEFINES THE 1/0 FEEDBACK AREA OF THE DISPLAY 

Ix FILE. THIS AREA CONTAINS THE NAME OF THE LAST 

Ix RECORD PROCESSED. THIS FIELD IS CALLED RECID. 

I* IOFB  : REDEFINES THE 1/0 FEEDBACK AREA FOR THE ICF 

Ix FILE. 

Ix 

[RR KKK KKK RR KAR KK RIK KIKI KK IK KAKI AKIRA KIKI KIKI IKI KIA KAR 


* 
ICMNFIL NS 80 1 CC 

1 RECCUS 
2  70CUSTNO 
8 37 DNAME 
38 43 DLSTOR 
44 52 DSLSTM 
DSPMO1 
62 70 DSPMO2Z 
71 79 DSPMO3 
80 90 DSTTYD 
91 93 IDEPT 
94 150 FILL20 


See eee eee 
on 
ies) 
fo 
i 


10/13/87 
10/13/87 
10/13/87 
03/20/89 
03/20/89 
03/20/89 
10/03/90 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 


KKK 
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AQ00000 
AQ00000 
A00000 
AQ00002 
AQ00003 
AQ00004 
B000000 
B000000 
Bo0000 
BOG0002 
B000003 
BO00004 
C000000 
C000000 
Co0000 
co00002 
C000003 
DO0eG00 
DO00000 
DeG0001 
DeG0002 
D000003 
DeG0004 
E000000 
E000000 
E000001 
E000002 
E000003 
F000000 
F000000 
FQ00001 
FQ00002 
F000003 
G000000 
G000000 
G000001 
Go00002 
G000003 
Go00004 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
I 


NS 81 


LCi 


RECITM 
70ITEMNO 
37 DESC 
440QTYLST 
510QTYOH 
580QTYOO 
650QTYBO 
67 UNIT 
742PRO 
800PRO5 
852UFRT 
942SLSTM 
1052SLSTY 
1142CSTTM 
1252CSTTY 
1302PRO 
1392L0S 
150 FILL10 


[RK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IK KK KK KKK KKK KEKE RERER 


I 


INPUT FIELDS FOR RECORD CIMENU FILE DSPFIL FORMAT CIMENU. 


MENU FOR INQUIRY 


INPUT FIELDS FO 


R RECORD DTLMNU 


CUSTOMER INQUIRY SCREEN 1 


INPUT FIELDS FO 


R RECORD DTLSCR 


CUSTOMER INQUIRY SCR. #2 


INPUT FIELDS FO 
ITEM INQUI 


INPUT FIELDS FO 
ITEM INQUI 


INPUT FIELDS FO 
ITEM INQUI 


INPUT FIELDS FO 


R RECORD ITMMNU 
RY SCREEN ONE 


R RECORD ITMSC2 
RY SCREEN TWO 


R RECORD ITMSC3 
RY SCREEN 3 


R RECORD TIMOUT 


TIME OUT SCREEN 


I0DS DS 


3. 3 *IN97 
2 2 *IN98 
1 *INQ9 
4 4 OPTION 
FILE DSPFIL FORMAT DTLMNU. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
4 90CUSTNO 
FILE DSPFIL FORMAT DTLSCR. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
FILE DSPFIL FORMAT ITMMNU. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
9OITEMNO 
FILE DSPFIL FORMAT ITMSC2. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
FILE DSPFIL FORMAT ITMSC3. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
FILE DSPFIL FORMAT TIMOUT. 
3. 3 *IN97 
2 2 *IN98 
1 *IN99 
4 4 TIMRSP 


1 240 FILLO1 
261 268 RECID 
271 415 FILLO2 


10/13/87 


0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 


10/13/87 
10/13/87 
10/13/87 
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ICF Programming V4R1 


0100 IIOFB DS 


1600 C* FILE IS OPENED. 


2400 Cx DISPLAY. 


2700 + 

BEGIN 
‘ICFOO 
"ICFO1 
"ICFO2 
‘ICFO3 


AaAaanananannaanaa 


MAIN 
4200 C 


5200 C* 
5400 +f 

5500 C READRQ 
5600 C 

5700 C RECID 
5800 C RECID 
5900 C RECID 
6000 C RECID 
6100 C RECID 
6200 C RECID 
6300 C 


a 
SS 
fo} 
La 
OQ 


4900 Cx BASED ON THE DISPLAY 


1400 Cx CALCULATION 
1500 C* THE DISPLAY DEVICE IS IMPLICITLY ACQUIRED WHEN THE 


TAG 

"ACQ CMNFIL 
"ACQ CMNFIL 
"ACQ CMNFIL 
"ACQ CMNFIL 
MOVEL' ICFOO 


WRITECIMENU 


DETERMINE USER'S REQUEST 


TAG 

READ DSPFIL 

CABEQ' CIMENU 
CABEQ' ITMMNU 
CABEQ' ITMSC2 
CABEQ' ITMSC3 
CABEQ' DTLMNU 
CABEQ'DTLSCR 
WRITECIMENU 

GOTO READRQ 


*ROUT 


INE 


415 


LOC 
ERR 
FILLO3 
FMTNM 
CMID 
MAJMIN 
MAJCOD 
MINCOD 
RECID2 
FILLO4 


SPECIFICATIONS 


"CMID 


"CMID 


"CMID 


"CMID 


"MENU 
"TTMIN 
"TTMRTN 
"TTMRTN 
"DTLIN 
"DTLRTN 


1800 C* ALL OF THE PROGRAM DEVICES ARE EXPLICITLY ACQUIRED. 


2000 Cx EACH OF THE FOUR TARGET PROGRAMS ARE EVOKED TO ESTABLISH 
2100 Cx TRANSACTIONS WITH THE REMOTE SYSTEMS. 


2300 Cx THE MAIN INQUIRY MENU (CIMENU) IS WRITTEN TO THE USER'S 


ZOO C&R KKK KAKA KARR KKK KKK KKK KKK KKK KKK KKK KKK KKK ERE KKK KKK KKK IKEA RR K 


1ST SESSION 
2ND SESSION 
3RD SESSION 
4TH SESSION 
1ST PROGRAM 
CALL EVOKE 
2ND PROGRAM 
CALL EVOKE 
3RD PROGRAM 
CALL EVOKE 
4TH PROGRAM 
CALL EVOKE 


4300 C&R KKK KKK KKH K KKK ERK KK KKK KKK KKK KKK KKK KK KKK EK KKK KKK KKK KKK IRIE K 


4700 Cx A READ OPERATION IS ISSUED TO THE DISPLAY PROGRAM DEVICE 
4800 Cx TO RECEIVE THE USER'S REQUEST. THE TYPE OF REQUEST MADE IS 
FORMAT CURRENTLY ON THE SCREEN. THE 
5000 C* RECORD FORMAT NAME IS EXTRACTED FROM THE 1/0 FEEDBACK AREA 
5100 C* AND USED TO DETERMINE WHAT ACTION SHOULD BE TAKEN NEXT. 


F300 C&R KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI KKK ERK RRR 


88 

MAIN MENU 

AT ITEM SCR? 
AT ITM SCR? 
AT ITM SCR? 
FOR DETAIL? 
CUST SCR? 
MAIN MENU 
THERE IS ERR 


03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
3 0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
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CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI IKKE KEKE RRR KKK 


C* 


*H 


MAIN MENU 


THE MAIN MENU IS READ TO DETERMINE THE REQUEST ENTERED BY 
THE USER. IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS ENDED. 


IF OPTION = 1, AN ITEM INQUIRY MENU IS WRITTEN TO THE SCREEN. 


IF OPTION = 2, A CUSTOMER INQUIRY MENU IS WRITTEN TO THE 
SCREEN. 


MENU TAG 
*IN99 CABEQ'1' END END PROGRAM 
OPTION IFEQ ‘1! 
WRITEITMMNU ITEM MENU 
ELSE 
WRITEDTLMNU CUST MENU 
END 
GOTO READRQ 


CRRA KKK KK KKK KKK KKK KKK KEK KKK KKK KKK KKK KKK KK KKK KKK KKK IRE KERR RE RRR 


ITEM INQUIRY 


THE ITEM NUMBER REQUESTED BY THE USER ON THE ITEM INQUIRY 
SCREEN IS CHECKED. THIS IS DETERMINED BY THE DISPLAY 
RECORD FORMAT BEING PROCESSED - IN THIS CASE ITMMNU. 


IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS ENDED. IF CMD 2 
IS PRESSED, THE ITEM INQUIRY REQUEST IS CANCELED, AND THE 
MAIN MENU (CIMENU) IS WRITTEN TO THE SCREEN. 


IF AN ITEM NUMBER IS ENTERED, A ITEM INQUIRY REQUEST IS 
SENT TO THE APPROPRIATE REMOTE SYSTEM. THE REMOTE SYSTEM 
IS SELECTED BASED ON THE ITEM NUMBER REQUESTED. 


IF AN ERROR OCCURS, THE ERROR IS PRINTED AND THE JOB 
IS ENDED. 


CRRA KKK KKK KKK KKK KI KKK KKK KK KKK KKK KKK KKK KK IK KIKI KKK IRE RIERE KERR ARK 


‘G 


QAaaanananannananananaanaan 


OQ 


ITMIN TAG 
*IN99 CABEQ'1' END EXIT ON CMD3 
*IN98 IFEQ '1' 

WRITECIMENU MAIN MENU 

GOTO READRQ 

END 


ITEMNO CABLE399999 XICFO1 
ITEMNO CABLE699999 XICFO2 
ITEMNO CABLE899999 XICFO3 
XICFO1 TAG 

MOVEL'ICFO1 ‘CMID 
GOTO XITMIN 
XICFO2 TAG 
MOVEL'ICFO2 'CMID 
GOTO XITMIN 


XICFO3 TAG 

MOVEL'ICFO3  ='CMID 
XITMIN TAG 

EXCPTITEMRQ INQ W/INV 
MAJCOD CABGE'04' ERROR ERROR RTN 
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10/13/87 
10/13/87 
10/13/87 
10/13/87 
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22600 
22700 
22800 
22900 
23000 
23100 
23200 
23300 
23400 
23500 
23600 
23700 
23800 
23900 
24000 
24100 
24200 
24300 
24400 
24500 
24600 
24700 
24800 
24900 
25000 
25100 
25200 
25300 
25400 
25500 
25600 
25700 
25800 
25900 
26000 
26100 
26200 
26300 
26400 
26500 
26600 
26700 
26800 
26900 
27000 
27100 
27200 
27300 
27400 
27500 
27600 
27700 
27800 
27900 
28000 
28100 
28200 
28300 
28400 
28500 
28600 
28700 
28800 
28900 
29000 
29100 
29200 
29300 


89 


N81 


AAaAaanaanaan 


c 


TRY89 TAG 
SETOF 
MOVEL' ' 
MOVEL' : 
READ CMNFIL 
EXSR ERRCHK 
MAJMIN CABGE'0300' 
EXCPTNOTITM 
SETOF 
MAJCOD CABGE'04' 
RECITM CABNE'I' 


89 
RECITM 
CMID 

891 

ITMIN 

81 
ERROR 
RECERR 


RESET RECID 


0 

FILE ERROR? 
NODATA? 

REC NOT FD? 


ERROR RTN 
PRINT MSG 


CRRA KKK KKK KKK KKK KKK KKK KEK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERE RE RE RE RE 


PROCESS ITEM I 


NFORMATION 


THE ITEM RECORD RECEIVED FROM THE TARGET PROGRAM AND THE 
INFORMATION ABOUT THE ITEM IS PROCESSED AND DISPLAYED. IF 
ITEMNO IS 0 OR LESS, IT IS AN INVALID REQUEST AND A FRESH 
ITEM MENU IS WRITTEN TO THE SCREEN. IF REQUEST IS VALID, 
VALUES ARE CALCULATED BASED ON THE INFORMATION RECEIVED. 


CRRA RARER KKK KKK KKK KKK KEK KKK KKK KKK KKK KKK KKK KIKI KKK ERE RERER EKER 


*H 


QAaaanananannnanananaanaan 


c 


ITMOUT TAG 
ITEMNO IFLE 000000 
WRITEITMMNU 


QAVAIL 70 
QAVAIL 
QAVAIL 
QAVAIL 
DSC 
QTYo 
QTYH 
QTYB 
UNT 
PRI 
PR5 
UFR 


ITEM MENU 
READ DISPLAY 


QTY AVAIL. 


ITEM DETAIL 


CRRA RAK KKK KKK KKK KKK KEK KK KKK KKK KKK KKK KKK KKK KKK IKK KEK EKER ERK KIRK 


ADDITIONAL ITEM 
ADDITIONAL ITEM INFORMATION IS 
IS DISPLAYED ON THE SCREEN WHEN 


IF CMD 1 (*IN99) IS PRESSED, TH 


AND THE MAIN MENU (CIMENU) IS W 


IF CMD 3 (*IN97) IS PRESSED, TH 
WRITTEN ON THE SCREEN. 


IF 'ENTER' IS PRESSED WHILE SCR 


DISPLAYED. 


IF 'ENTER' IS PRESSED WHILE SCR 


TO THE SCREEN. 


INFORMATION 


PROCESSED AND TH 
A RESPONSE IS R 


RITTEN TO THE SC 


E ITEM INQUIRY M 


EEN 2 FOR ITEM R 


EEN 3 FOR ITEMR 


E PROGRAM IS ENDE 


E RESULT 
EAD 


FROM THE DISPLAY WITH AN ITEM SCREEN RECORD FORMAT. 


i= 


IF CMD 2 (*IN98) IS PRESSED, THE ITEM INQUIRY IS ENDED, 


REEN. 


ENU IS 


EQUESTED IS 


CURRENTLY DISPLAYED, MORE INFORMATION IS CALCULATED AND 


EQUESTED IS 


CURRENTLY DISPLAYED, THEN THE ITEM INQUIRY MENU IS WRITTEN 


CRRA KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK K IK IKI KKK EKER KKK ARR 


0/13/87 
0/13/87 
0/13/87 
0/13/87 
23 0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/13/87 
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29400 
29500 
29600 
29700 
29800 
29900 
30000 
30100 
30200 
30300 
30400 
30500 
30600 
30700 
30800 
30900 
31000 
31100 
31200 
31300 
31400 
31500 
31600 
31700 
31800 
31900 
32000 
32100 
32200 
32300 
32400 
32500 
32600 
32700 
32800 
32900 
33000 
33100 
33200 
33300 
33400 
33500 
33600 
33700 
33800 
33900 
34000 
34100 
34200 
34300 
34400 
34500 
34600 
34700 
34800 
34900 
35000 
35100 
35200 
35300 
35400 
35500 
35600 
35700 
35800 
35900 
36000 
36100 
36200 
36300 
36400 
36500 


END 


PROFM 
PROFM 


92 


PROFM 
LOSTS 
SLSM 
SLSY 
CSTM 
PROFIT 
CSTY 


JOB ENDS 


MAIN MENU 


CMD 3 ? 
ITM SCR 2 ? 
YES, THEN ITS 
ITEM MENU 


ITM SCR 3 ? 
YES, THEN ITS 
ITEM MENU 


PROFIT MONTH 
46 


PROFIT PCT 
LOST SALES 


ITEM DTL 2 


CRRA KARR KKK KKK KKK KKK KEK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERE RRR ERE RRR 


CUSTOMER INQUIRY 


IF CMD 1 (*IN99) IS PRESSED, THE PROGRAM IS ENDED. 


SYSTEM. 


ROGRAM. 


THE REQUEST FROM THE CUSTOMER INQUIRY MENU IS PROCESSED. 


IF CMD 2 (*IN98) IS PRESSED, THE CUSTOMER INQUIRY IS ENDED, 
WRITTEN TO THE SCREEN. 


IF A CUSTOMER NUMBER IS ENTERED, THE CUSTOMER INQUIRY 


A READ TO THE PROGRAM DEVICE IS ISSUED TO RECEIVE THE 


IF AN ERROR OCCURS, THE ERROR IS PRINTED AND THE JOB IS 


CRRA KKK KKK KKK KKK KKK KK KKK KKK IK KKK IKK KKK KKK IKK KKK KERIKERI KERR 


Cc ITMRTN TAG 

C *IN99 CABEQ'1' 

C *IN98 IFEQ '1' 

C WRITECIMENU 
C GOTO READRQ 
C END 

C *IN97 IFEQ '1' 

Cc RECID IFEQ 'ITMSC2 
C RITEITMMNU 
C GOTO READRQ 
C END 

C END 

Cc RECID IFEQ 'ITMSC3 
C WRITEITMMNU 
C GOTO READRQ 
C END 

C SLSTM SUB CSTTM 
C MULT 100 

C SLSTM COMP 0 

Cc N46 PROFM DIV SLSTM 
C QTYLST MULT PRO1 

C MOVE SLSTM 
C MOVE SLSTY 
C MOVE CSTTM 
C MOVE PROFM 
C MOVE CSTTY 
C WRITEITMSC3 
C GOTO READRQ 
Cx 

Cx 

Cx 

Cx 

Cx 

Cx 

Cx 

Cx 

Cx AND THE MAIN MENU (CIMENU) IS 
Cx 

Cx 

Cx REQUEST IS SENT TO THE REMOTE 
Cx 

Cx 

Cx INFORMATION FROM THE TARGET P. 
Cx 

Cx 

Cx ENDED. 

Cx 

*O 

C DTLIN TAG 

C *IN99 CABEQ'1' 

C *IN98 IFEQ '1' 

C WRITECIMENU 
C GOTO READRQ 
C END 

Cc EVDTL TAG 

C MOVE CUSTNO 
C MOVEL' ICFOO 
C EXCPTITEMRQ 
C MAJCOD CABGE'04' 

C TRY88 TAG 

C MOVEL' 

C MOVEL' 

C SETOF 

C READ CMNFIL 
C 88 EXSR ERRCHK 
Cc MAJMIN CABGE' 0300' 
C N80 EXCPTNOTCUS 
C RECCUS CABNE'C' 

C SETOF 
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ICF Programming 


END 


ITEMNO 
"CMID 


ERROR 


"CMID 
RECCUS 


EVDTL 


RECERR 


JOB ENDS 


MAIN MENU 


SEND CUST # 
ERROR RTN 


RESET RECID 


88 
8810REC CUS INF 
FILE ERR? 
NODATATRYAGN 
RECD NOT FD? 
PRINT MSG 
80 


1 


2.3 


03/20/89 


0/ 


3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 


13/87 


3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 


13/87 


3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 
3/87 


13/87 


3/87 
3/87 


. Source Program Example — RSFMUL (System-Supplied Formats) 


V4R1 


BE6OQ C&R KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK ERK KK KKK KKK KIKI K IRR K 


36700 C 


* 


THE CUSTOMER DATA REC 
PROCESSED. IF CUSTOME 
INVALID REQUEST AND T 


WHEN THE RCVTRNRND IN 
CUSTOMER INFORMATION 


IF DURING THE READ OP 
CONTROL GOES TO THE E 


PROCESS CUSTOMER INFORMATION 


EIVED FROM THE TARGET 
R NUMBER IS ZERO OR LESS, IT IS AN 
HE MAIN MENU IS WRITTEN TO THE SCREEN. 


ERATION AN ERROR IS R 
RROR ROUTINE TO END TI 


PROGRAM IS 


DICATOR(*IN90) IS RECEIVED, THE 
IS WRITTEN TO THE SCREEN. 


ECEIVED, 
HE JOB. 


BBOOQ C&R KKK KKK KKK KKK H KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK IKKE 


w 

foe) 

wo 

fo} 

La?) 
AaAaanananananaanaana 


39700 C 


0400 C 


Rp 

wo 

fo} 

a>) 
AaAaanananananaanna 


w 
a 
f=) 
oO 
OQ 


* 


* 


* 


‘a 


DTOUT 
CUSTNO 


TAG 


IFEQ 000000 
SETOF 

WRITECIMENU 
GOTO READRQ 


CUSTNO 
LDNAME 
DLSTOR 
DSLSTM 
DSPMO1 
DSPMO2 
DSTTYD 
IDEPT 
EDTLSCR 


GOTO READRQ 


B9BQQ C&R KKK KKK KKK K KK HK KK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI K IRR K 


CUSTN 
CNAME 
DLSTR 
DSLSM 
DSPM1 
DSPM2 
DSTYD 
DEPT 


66 
MAIN MENU 


DETAIL INFO 


THIS ROUTINE HANDLES THE USER'S REQUEST FOLLOWING THE 
DISPLAY OF THE CUSTOMER INFORMATION. 
THE JOB, CMD KEY 2 WILL DISPLAY THE MAIN MENU, AND "ENTER" 


WILL BRING UP THE CUSTOMER INQUIRY MENU. 


DTLRTN 
*IN99 
*IN98 


TAG 


CABEQ'1 
IFEQ '1' 

WRITECIMENU 
GOTO READRQ 


END 


WRITEDTLMNU 
GOTO READRQ 


END 


CMD KEY 1 WILL END 


Q5 OQ Cx KKK KKK KK KKK KKK KEK KKK KKK KKK KKK KKK KKK KEK ERE KERR KKK KKK KKK IKI K 


JOB ENDS 


MAIN MENU 


CUSTOMER INQ 


L500 Cea KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KEK KKK KKK KKK KKK KKK KIKI KIRKE ER ER 


WHEN AN 1/0 OPERATION ERROR IS DETECTED, A MESSAGE IS PRINTED 
AND THE TRANSACTION AND SESSION ARE ENDED FOR EACH OF THE 


REMOTE SYSTEMS. 


RECERR 


ERROR 


END 


TAG 
EXC 
GOT 
TAG 
EXC 
TAG 


EXC 


EXC 
MOV 
EXC 
MOV 
EXC 


MOVE 


MOVE 


p 


0 
p 
p 


p 


Umum 


TRECER 
END 


TMMERR 


L'ICFOO 
TDETACH 
L'ICFO1 
TDETACH 
L'ICFO2 
TDETACH 
L'ICFO3 
TDETACH 


"CMID 


"CMID 


"CMID 


"CMID 


21OQ C&R KK KKH K KKH K KKK KK KKK KKK KKK KKK KKK KKK KKK KEK KKK KKK KK IK IKI K IKI ERR 


WRONG RECID 
END PROGRAM 


DET 1ST TRANS 


DET 2ND TRANS 


DET 3RD TRANS 


DET 4TH TRANS 
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C ABORT TAG 

C "ICFOO = 'REL = CMNFIL 86 REL 1ST SESS 
Cc "ICFO1 ='REL = CMNFIL 86 REL 2ND SESS 
Cc "ICFO2 = 'REL = CMNFIL 86 REL 3RD SESS 
C "ICFO3 ‘REL = CMNFIL 86 REL 4TH SESS 
C FORCE TAG 

C SETON LR 

C RETRN 

CARH KAKA KRHA KK KIKI KK KKK KKK KIKI IK IKKE RIKER IK IKARIA IK IR IRIE R ERA. 
Cx 

Cx THIS SUBROUTINE IS CALLED TO EVOKE THE TARGET PROGRAM. THE 
Cx SAME TARGET PROGRAM (ICFLIB/RTDMULCL) IS EVOKED AT FOUR 


Cx DIFFERENT REMOTE SYSTEMS. THE PROGRAM DEVICE IDENTIFIES 
Cx WHICH SESSION SHOULD BE EVOKED. THE PROGRAM DEVICE WAS 
Cx SPECIFIED IN CMID PRIOR TO CALLING THIS ROUTINE. 


Cx 

CK KKK RK RIK KKK KR KIRK KK IKK KIKI KKK IKK KAKI KIKI KIKI KK IK III RK. 
a 13 

Cc EVKSR BEGSR 

C EXCPTEVOKE EVOKE TARGET 

C ENDSR 

CRRA K RK RIK KKK KA KR KIKI KK KIKI AKAIKE IKI KIKI KIKI AKIRA KIA KIA K 

Cx 


Cx THIS SUBROUTINE IS CALLED TO PERFORM FURTHER CHECKS ON FILE 
Cx ERRORS RESULTING FROM THE READ OPERATION ISSUED TO THE PRO- 


Cx GRAM DEVICE. THIS ROUTINE CHECKS FOR THE TIME OUT INDICATION. 


Cx IF THERE IS A TIME OUT, THEN A MESSAGE IS SENT TO THE USER'S 
Cx DISPLAY SCREEN REQUESTING ACTION, OTHERWISE PROGRAM ENDS. 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK I KIKI KKK KEE RK KKK 


‘i 

C ERRCHK BEGSR 

C MAJMIN IFEQ '0310' TIMER EXPD? 
C CHKAGN TAG 

Cc WRITETIMOUT DISPLAY MSG 
C READ DSPFIL 87READ REPLY 
C 88 TIMRSP CABEQ'1' TRY88 CUST INQUIR 
Cc 89 TIMRSP CABEQ'1' TRY89 ITEM INQUIR 
Cc TIMRSP IFEQ '2' END PROGRAM 
C EXCPTEOS END SESSION 
C GOTO FORCE END PROGRAM 
C END 

C GOTO CHKAGN ASK AGAIN 

C END 

C MAJMIN CABEQ'0300' ERRESR TRN/NODATA 
C MAJMIN CABEQ'0000' ERRESR TRN W/DATA 
C GOTO ERROR ABEND 

C ERRESR TAG 

C ENDSR 

CHR KRHA KA KRHA KK EKA KKK KK KR EK IKE KIKI KI KR EK KERIKERI KIKI R IR IK IERIE. 
Cx 


Cx THIS IS THE PROGRAM ERROR SUBROUTINE THAT RECEIVES CONTROL 
Cx WHEN AN ERROR OCCURS AFTER AN I/O OPERATION IS ISSUED TO THE 
Cx PROGRAM DEVICE AND THERE IS A NON-ZERO VALUE IN THE RPG 

Cx STATUS FIELD (ERR). THIS ROUTINE CHECKS FOR STATUS VALUES 

Cx THAT RELATE TO ICF OPERATIONS. IF THE PROGRAM DEVICE 

Cx IS ALREADY ACQUIRED, THE ERROR IS IGNORED, OTHERWISE THE 

Cx PROGRAM IS TERMINATED. 


Cx 

CHR KRHA KAKA KK KK ERIK IKK KKK KEKE KIKI K IKI R EKER KIKI KIKI IK IR ERIKA. 
‘i 

C *PSSR BEGSR 

C MOVE ' "RETURN 6 DEFAULT 

C ERR CABEQO1285 ENDPSR ALREADY ACQ? 
C MOVE '*CANCL' RETURN JOB ENDS 

Cc ENDPSR ENDSRRETURN BACK TO MAIN 


CRRA KKK K KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KIKI K KKK RRR RKK KARI 


NNN DY 


0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/16/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/14/87 
0/14/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
0/03/90 
03/20/89 
03/20/89 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/14/87 
0/13/87 


Figure 11-21 (Part 9 of 14). Source Program Example — RSFMUL (System-Supplied Formats) 


11-60 


ICF Programming V4R1 


50400 
50500 
50600 
50700 
50800 
50900 
51000 
51100 
51200 
51300 
51400 
51500 
51600 
51700 
51800 
51900 
52000 
52100 
52200 
52300 
52400 
52500 
52600 
52700 
52800 
52900 
53000 
53100 
53200 
53300 
53400 
53500 
53600 
53700 
53800 
53900 
54000 

* 6103 
H000000 
H000000 
1000000 
1000000 
J000000 
J000000 
J000001 
J000002 
J000003 
J000004 
J000005 
J000006 
J000007 
J000008 
J000009 
K000000 
K000000 
L000000 
L000000 
L000001 
Loe0002 
L000003 
L000004 
L000005 
L000006 
L000007 
L000008 
L000009 


OQPRINT E 1 


El 


El 


Eel 


CMNFIL E 


ooooooceocceocceoocooce°oce°c°oce°oce°ce°ceoeocecoceoceceoco°cecoococoe 


MMERR 


MAJCOD 


MINCOD 


FMTNM 


CMID 
RECER 


CUSTNO 


DNAME 
EVOKE 


ITEMRQ 


ITEMNO 
DETACH 


EOS 


K5 
4 


54001 OVERFLOW INDICATOR OA ASSIGNED 
OUTPUT FIELDS FOR RECORD CIMENU FILE DSPFIL FORMAT CIMENU. 


MENU FOR INQUIRY 


"COMMUNICATION ERROR. 
"MAJOR/MINOR: 


y 
"FORMAT: ' 

"PGMDEV: ' 

"UNMATCH RECORD FORMAT ' 
"-JOB ENDED. ' 

"NOT ITEM RECD-' 


pS 


"NOT CUST RECD-' 


vp 


"$SEVOKNI 
"RTFMULCL' 
‘ICFLIB ' 


"$$SEND' 
0006' 


"$$SENDET' 
‘9000! 


'$$EOS' 
'9000' 
TO FILE QPRINT. 


OUTPUT FIELDS FOR RECORD DTLMNU FILE DSPFIL FORMAT DTLMNU. 
CUSTOMER INQUIRY SCREEN 1 
OUTPUT FIELDS FOR RECORD DTLSCR FILE DSPFIL FORMAT DTLSCR. 
CUSTOMER INQUIRY SCR. #2 


CUSTN 
DEPT 

DLSTR 
DSLSM 
DSPM1 
DSPM2 
DSPM3 
DSTYD 
CNAME 


CHAR 6 
ZONE 3,0 
ZONE 6,0 
ZONE 9,0 
ZONE 9,0 
ZONE 9,0 
ZONE 9,0 
ZONE 11,0 
CHAR 5 


OUTPUT FIELDS FOR RECORD ITMMNU FILE DSPFIL FORMAT ITMMNU. 
ITEM INQUIRY SCREEN ONE 
OUTPUT FIELDS FOR RECORD ITMSC2 FILE DSPFIL FORMAT ITMSC2. 
ITEM INQUIRY SCREEN TWO 


CHAR 
ZONE 
ZONE 
ZONE 
ZONE 
CHAR 
ZONE 
ZONE 
ZONE 


w 


NNN 
NONNDTDOOO®D 


ann 


0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
0/13/87 
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MQQ0000 OUTPUT FIELDS FOR RECORD ITMSC3 FILE DSPFIL FORMAT ITMSC3. 
M000000 ITEM INQUIRY SCREEN 3 
MO00001 SLSM 9 ZONE 9,2 
M000002 SLSY 20 ZONE 11,2 
M000003 CSTM 29 ZONE 9,2 
M000004 CSTY 40 ZONE 11,2 
M000005 PROFIT 45 ZONE 5,2 
M000006 LOSTS 54 ZONE 9,2 
NOOOGGO OUTPUT FIELDS FOR RECORD TIMOUT FILE DSPFIL FORMAT TIMOUT. 
Noo0000 TIME OUT SCREEN 
**e**e** END OF SOURCE ** * * * 
Additional Diagnostic Messages 
* 7089 4500 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE CMNFIL. 


Cross Reference 
File and Record References: 
FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 


01 CMNFIL WORKSTN 4500D 6500 7700 12900 13000 
13100 13200 23000 36000 43800 
43900 44000 44100 52700 53100 
53500 53800 
$$E0S 53900 
$$EVOKNI 52800 
$$SEND 53200 
$$SENDET 53600 
02 DSPFIL WORKSTN 5000D 15600 47200 
CIMENU 5000D AQQ0000 4200 16300 20900 
29800 34800 38500 41000 000000 
DTLMNU 5000D BO00000 8200 41300 1000000 
DTLSCR 5000D C000000 39600 J000000 
ITMMNU 5000D DOQ0000 8000 25100 30300 


30800 K000000 


ITMSC2 5000D E000000 26600 LQQ0000 

ITMSC3 5000D FOQ0000 32100 MQ00000 

TIMOUT 5000D GOQ0000 47100 NQ00000 

03 QPRINT PRINTER 5200D 50400 51400 51700 52200 
54001 
Field References: 

FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 

*IN97 A(1) A000001 BOOOOO1 C000001 DOODOO01 £000001 
FQ00001 GO00001 30100 

*IN98 A(1) AQ000002 BOLOOOZ CHO0002 DODOBE2 £E000002 
Fo000e2 Go0R002 20800 29700 34700 
40900 

*IN9O A(1) A000003 BOO0003 C000003 DODOOO3 £E000003 


FO00003 GO00003 17800 20700 29600 
34600 40800 
*PSSR BEGSR 4500 49800D 
* 7031 ABORT TAG 43700D 
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* 7031 


* 7031 


* 7031 


7031 
7031 
7031 
7031 
7031 
7031 


ee HF FF 


BEGIN 
CHKAGN 
CMID 


CNAME 
CSTM 
CSTTM 
CSTTY 
Coy 
CUSTN 
CUSTNO 


DEPT 
DESC 
DETACH 
DLSTOR 
DLSTR 
DNAME 
DSC 
DSLSM 
DSLSTM 
DSPMO1 
DSPMO2 
DSPMO3 
DSPM1 
DSPM2 
DSPM3 
DSTTYD 
DSTYD 
DTLIN 
DTLRTN 
DTOUT 
END 


ENDPSR 
EOS 
ERR 
ERRCHK 
ERRESR 
ERROR 

EVDTL 


TAG 
TAG 
A(10) 


A(5) 
P(9,2) 
P(9,2) 
P(11,2) 
P(11,2) 
A(6) 
P(6,0) 


P(3,0) 
A(30) 
EXCPT 
A(6) 
P(6,0) 
A(30) 
A(30) 
P(9,0) 
A(9) 
A(9) 
A(9) 
A(9) 
P(9,0) 
P(9,0) 
P(9,0) 
A(11) 
P(11,0) 
TAG 
TAG 
TAG 
TAG 


ENDSR 
EXCPT 
Z(5,0) 
BEGSR 
TAG 
TAG 
TAG 
BEGSR 
EXCPT 
A(240) 
A(145) 
A(240) 
A(145) 
A(11) 
A(57) 
A(8) 
TAG 
A(3) 
DS(415) 
DS(415) 
P(6,0) 


EXCPT 
TAG 
TAG 
TAG 
A(8) 
P(9,2) 
P(9,2) 


12800D 
47000D 
10600D 
21600M 
35700M 
51300 
38900M 
31800M 
9100D 
9200D 
32000M 
38800M 
6700D 
52400 
39500M 
8000D 
43000 
6900D 
39000M 
6800D 
25800M 
39100M 
7000D 
7100D 
7200D 
7300D 
39200M 
39300M 
J000007D 
7400D 
39400M 
6100 
6200 
38200D 
7800 
42500 
50000 
47600 
0300D 
23100 
48100 
22500 
35100D 
3400 
45600 
9800D 
0000D 
0400D 


7900D 
25000 
22400 
15800 
24900D 
15900 
10200D 

9400D 
31500M 


47900 

13300M 
21900M 
42900M 


J000009D 
M000003D 
31100 
32000 
M000004D 
J000001D 
BO00004D 


J000002D 
25800 
43200 
39000 
J000003D 
38900 
L000001D 
J000004D 
39100 
39200 
39300 


J000005D 
J000006D 


39400 
J000008D 

34500D 

40700D 


20700 
42800D 
50200D 
53800 
50000 
36100 
48200 
23500 
36200 
13600 
52700 


51100 
47700 
39500 
9700D 
10100D 
De00004D 
35200M 
35400 
20600D 


16000 


MO00006D 


13500M 
22200M 
43100M 


31800 


35200 


52100 
43400 


52600 


29600 


46800D 
48400D 
35500 


13800 


21200 
51900 
53100 
23200 


29500D 


13700M 
22900M 
43300M 


38300 


43600 


34600 


42600D 


14000 


21300 
53400 


13900M 
35300M 
43500M 


38800 


53500 


40800 


48300 


45500D 


21400 
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* 7031 


* 7031 


* 7031 


MAIN 
MAJCOD 
MAJMIN 


MENU 
MINCOD 
MMERR 
NOTCUS 
NOTITM 
OPTION 


XITMIN 


"*CANCL' 
'C! 
"CIMENU 
"DTLMNU 
'DTLSCR 
YT! 
‘ICFOO 
‘ICFO1 
‘ICFO2 
‘ICFO3 
‘ TTMMNU 
‘I TMSC2 
‘IT TMSC3 
‘0000' 
'0300' 
0310! 
104! 


TAG 
A(2) 
A(4) 


TAG 
A(2) 
EXCPT 
EXCPT 
EXCPT 
A(1) 
P(5,2) 
P(5,2) 
P(9,2) 
P(7,2) 
P(6,0) 
P(7,2) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
P(7,0) 
TAG 


A(1) 
EXCPT 
TAG 
A(8) 


A(8) 
A(1) 
A(6) 
P(9,2) 
P(9,2) 
P(11,2) 
P(11,2) 
A(1) 
TAG 
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LITERAL 
LITERAL 


14100D 
10800D 
10700D 
48200 
15700 
10900D 
42700 
36300 
23300 
A000004D 


8900D 
9000D 
31700M 
G000004D 
35600D 
22600D 
26500M 
8800D 
8500D 
26200M 
21200 
21300 
21400 
21700 
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22500 
23200 


17700D 
50900 
50400 
52200 
51700 
17900 


MO00005D 
31200M 
26300 
26400 

L000007D 

L000008D 
25500M 

LO00005D 
25700 

L000003D 
31500 

L000004D 
25500 
25600 
16400 
29900 
38600 
35800M 
51400 
36400 
15700 
16200 


22800M 
50100M 
M000001D 
31100 
31700 
Mo00002D 
47300 
47300 
47400 
L000009D 
26500 
26200 
L000006D 
21500D 
21800D 
22100D 
22000 
35700 


35800 


13300 
13500 
13700 
13900 


30200 
30700 


36200 


23500 


23500 
36200 


31400 
31500 


25600M 


26100 


26000 
25900 
18400 
30400 
39700 
36400 


42300D 
15800 
30200 


23600 
50200 


31300 


47400 


22300D 


35300 
21600 
21900 
22200 


48100 


35500 


35500 50700 
46900 48100 
31400M 31900 


25700M LQ00002D 


21000 25200 
30900 32200 
41100 41400 
15900 16000 
30700 

31400 31600 
47500 

42900 43800 
43100 43900 
43300 44000 
43500 44100 


‘1! LITERAL 17800 17900 20700 20800 29600 
29700 30100 34600 34700 40800 
40900 47300 47400 
12" LITERAL 47500 
) LITERAL 25400 31300 
000000 LITERAL 25000 38300 
01285 50000 
100 31200 
399999 21200 
699999 21300 
899999 21400 
Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 
*IN A000001 A000002 A000003 BOOO001 BO0OO0O2 BO000O3 
Co00001 Co00002 CH00003 DOO0O01 DOD0002 DOD0003 
EQ00001 EQ000O2 E0DO0003 FOOOOO1 FOOOOO2 FOROOOO3 
GO00001 G000002 GO00003 17800 20700 20800 
29600 29700 30100 34600 34700 40800 
40900 
LR 44300M 
0A 5200D 54001 
* 7031 10 23000M  36000M 
46 31300M 31400 
* 7031 66 38400M 
80 6500M 36300 36500M 
81 7700M 23300 23400M 
* 7031 86 43800M 43900M 44000M  44100M 
* 7031 87 47200M 
88 15600M 35900M  36000M 36100 47300 
89 22700M 23000M 23100 47400 
97 A000001 BO00001 C000001 DOO0001 £000001 F000001 
G000001 30100 
98 A000002 BO00002 C000002 DOO0D02 £E000002 F000002 
G000002 20800 29700 34700 40900 
99 A000003 B000003 C000003 DO00003 £000003 F000003 
G000003 17800 20700 29600 34600 40800 
x**e*** END OF CROSS REFERENCE ** * * 
Message Summary 
* QRG6103 Severity: 00 Number: al 
Message... . 3: No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 
* QRG7031 Severity: 00 Number: 20 
Message... .: The Name or indicator is not referenced. 
* QRG7089 Severity: 00 Number: 1 
Message... . : The RPG provides Separate-Indicator area for 
file. 


**x*e*e*e END OF MESS 


Final 
Message Count: (by Severity Number) 
TOTAL 00 10 20 


22 22 0 0 
Program Source Totals: 
Records: 's 1. ee ceca et BAO 
Specifications ......: 296 
Table Records .......: O 
Comments .......2..: 244 


PRM has been called. 


Program RSFMUL is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**x*x*e* END OF COMPILATION 


AGE 


SUMMARY 


Summary 


Kk KKK 


x kK KK * 


Figure 11-21 (Part 14 of 14). Source Program Example — RSFMUL (System-Supplied Formats) 


Target Program Multiple-Session Inquiry (Example 
Il): The following describes a target program for the 


multiple-session inquiry. 


Program Files: The RPG/400 multiple-session example 


target program uses the following 
CFILE 


files: 


An ICF file used to send records to and receive 
records from the source program. 


PFILE 
A database file used to retrieve the requested infor- 
mation to send to the source program. 


QPRINT 
A printer file used to print error messages resulting 
from communications errors. 


DDS Source: The DDS source for the ICF file (CFILE) is 
illustrated in Figure 11-22 on page 11-66. 
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SOURCE FILE. ...... QICFPUB/ICFLIB 


MEMBER? cs se. <p. co 8, 98) 3 ses os CFILE 

SEQNBRE se Ps sna Le eethived 2. ole tees eS we otae et Ah Ske his. bes cte as Ov anethias SP meetiad Oo eet ene Qi thaeg Q 
100 N&R RRR KK RARER RK ERR KER RRR RRR ERR ER ERE RRR ERE KER EKER EKER ER ER ERE REE ERE 10/14/87 
200 Ax * 10/14/87 
300 Ax ICF FILE * 10/14/ 
400 Ax USED IN TARGET MULTIPLE SESSION PROGRAM * 10/14/87 
500 Ax * 10/14/87 
600 N&R KKK EK RARER RRR RRR ERE RE REE RRR ERE RE RRR ERE KER EKER ER ERE REE ER ER ERE 10/14/87 
700 A INDARA 08/04/87 
800 A 05 RQSWRT 08/04/87 
900 A 10 ALWWRT 08/04/87 
1000 A INDTXT(10 '10 END TRANS.') 08/04/87 
1100 A 15 EOS 08/04/87 
1200 A 20 FAIL 08/06/87 
1300 A INDTXT(20 '20 F ABORT ST') 08/06/87 
1400 A RCVFAIL(25 ‘RECEIVED FAIL') 08/04/87 
1500 A 30 DETACH 08/06/87 
1600 A INDTXT(30 '30>DETACH TGT') 08/06/87 
1700 A RCVDETACH(44 'RECV DETACH') 08/04/87 
1800 A R SNDPART 08/04/87 
1900 A INVITE 08/14/87 
2000 A RECTYP 1 10/01/87 
2100 A ITEMNO 6 10/08/87 
2200 A EDATA 130 08/04/87 
2300 A FILL1 13 10/08/87 
2400 A R RCVPART 08/04/87 
2500 A RECID2 6 10/08/87 
2600 A PARTDS 80 10/08/87 
2700 A FILL4 64 08/04/87 
2800 A R RCVTRND 08/07/87 
2900 A RCVTRNRND(40 ‘END OF TRN') 08/07/87 

x**** END OF SOURCE *** * 

Figure 11-22. DDS Source for ICF File Used by Target Program Multiple-Session Inquiry 

The DDS for the database file (PFILE) is illustrated in 

Figure 11-23. 

SOURCE FILE. ...... QICFPUB/ICFLIB 

MEMBER ......... PFILE 

SEQNBRE vives 6.20 Liseceethe ea Covel et cate BS stb A aa te ede Dect O: acted J Resta Oe eete ae Okie Q 
100 A LIFO 07/02/87 
200 A R DBREC 05/06/87 
300 A RECCUS 1 10/01/87 
400 A DBSEQ 6 08/18/87 
500 A DBDATA 130 07/02/87 
600 A DBFILL 13 10/01/87 
700 A K DBSEQ 07/04/87 


x**** END OF SOURCE 


kK kK KK 


Figure 11-23. DDS Source for Database File Used by Target Program Multiple Session Inquiry 


ICF File Creation and Program Device Entry Definition: 
The command needed to create the ICF file is: 


CRTICFF FILE(ICFLIB/CFILE) SRCFILE(ICFLIB/QICFPUB) 
SRCMBR(CFILE) ACQPGMDEV(RQSDEV) TEXT("TARGET ICF FILE 
FOR MULTIPLE SESSION PROGRAM") 


The command needed to define the program device entry is: 
OVRICFDEVE PGMDEV(RQSDEV) RMTLOCNAME (*REQUESTER) 


Program Explanation: The following explains the structure 
of the program examples illustrated in Figure 11-24 on 

page 11-68 and Figure 11-25 on page 11-73. The ICF file 
used in the first example is defined by the user, and uses 
externally described data formats (DDS). The second 
example uses the same file, but uses program-described 
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data and system-supplied formats. The reference numbers 
in the explanation below correspond to the numbers in the 
program examples. 


Although the basic structure of the two examples provided is 
the same, there are differences because of the way the user- 
defined formats and the system-supplied formats are used. 
All output operations to the ICF file in the first example are 
done using the WRITE operation. All output operations in 
the ICF file in the second example using system-supplied 
formats are done using the EXCPT operation. 


Differences between the first and second example are 
described as notes in each of the following descriptions 
where necessary. 


The file specification defines the files used in the 
program. 


CFILE is the ICF file used to send records to and 
receive records from the source program. 


The files used in the program are implicitly opened at 
the beginning of the RPG/400 cycle when the program 
starts. 


Note: In the program using system-supplied formats, 
the input records for CFILE are explicitly coded in the 
program since CFILE is now described as a program- 
described file. The system-supplied file QICDMF can 
be used instead of CFILE. To use QICDMF, specify 
QICDMF in the file specification, or use an OVRICFF 
command to change the file name from CFILE to 
QICDMF. 


The continuation lines on the file specification for 
CFILE define the data structure name — FEEDBK for 
the feedback area (INFDS). FEEDBK contains the fol- 
lowing information, which is used to monitor for error 
conditions after an I/O operation is issued to CFILE: 


e Record format-name (FMTNM) 
¢ Program device name (PGMDEV) 
¢ Major/minor return code (MAJMIN) 


A read operation is issued to the program device to 
receive an inquiry request from the source program. If 
an error occurs on the read operation (a major code 
greater than 03), control passes to [j. 


If a detach indication is received, control goes to [¥. 
Otherwise, the program goes to —]. When a detach is 
received, indicator 44 is set on, as defined by the 
RCVDETACH keyword in the DDS for the ICF file. 


Note: In the program using system-supplied formats, 
a minor return code of 08 is checked to determine if a 
detach indication was received. Also, the read opera- 
tion is issued using file name CFILE in factor 2, 
whereas in the user-supplied format example, it is 
issued using a record format name. 


If a turnaround indication was not received in 4, the 
program continues to read the ICF file until the indi- 
cation is received. 


If an error occurs (a major return code greater than 03 
is returned from the read operation), the program goes 
to J. Otherwise, the program goes to [g. 


The program also tests to see whether the receive 
detach indicator (indicator 44) is set. If it is, the 
program goes to fj. 


Note: In the program using system-supplied formats, 
a minor return code 00 is checked to determine if 
change direction occurred and a minor return code of 
08 for a detach indication received. 


The program uses the requested number received from 
the source program to access the record from the data- 
base. The information retrieved from the database file 
(PFILE) is moved into the work area for the ICF file. A 
write operation is issued to the ICF program device 
using record format SNDPART. The write operation 
sends the requested information back to the source 
program. 


If the requested number is not found, zero is propa- 
gated into the field. 


If an error occurs on the write operation (a major return 
code greater than 03), control passes to fj. 


If no error occurs on the write, the program goes back 
to @. 

Note: In the program using the system-supplied 
format, the write operation uses the $$SEND format to 
send the data. 


When an error in an I/O operation is detected, an 
EXCPT operation is issued to print an error message 
saying that an error has occurred on the ICF file. The 
major/minor return code is also printed. 


The program then goes to J. 


Control passes here whenever the program has 
detected a communication error, or received a detach 
indication from the source program. The last record 
indicator is set on, which ends the program. CFILE is 
implicitly closed. 


This subroutine is called for I/O operation errors that 
are not handled by subroutine [J. This subroutine 
checks whether the program device is already acquired 
when an acquire operation is requested, and, if so, the 
second acquire is ignored. Otherwise, the program 
ends. 
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Compiler. .......4..... 2: IBM AS/400 RPG/400 
Command Options: 
Program ....... 2... 2) ICFLIB/RTDMUL 
Source file .......... :  ICFLIB/QICFPUB 
Source member .........: = *PGM 
Text not available for message RXT0073 file QRPGMSG. 
Generation options. ......:  *NOLIST *NOXREF *NOATR 
Source listing indentation... :  »*NONE 
SAA flagging. ......... =: + *NOFLAG 
Generation severity level ...: 9 
Print file... ....... . 2  *LIBL/QSYSPRT 
Replace program ........: ~~ ¥*YES 
Target release... ..... =. : = *CURRENT 
User profile. ......... :  ¥*USER 
Authority ........... :  *LIBCRTAUT 
Texte eee ee a ee ee | CRSRCMBRTXT 
Phase trace ..........: = *NO 
Intermediate text dump... .. :  “*NONE 
Snap dump .......... +. :  *NONE 
Codelist .........+.+. +. : + *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member... ... 2... 2... 2: = RIDMUL 
FAG Se eee ee we wea doe eo CQICEPUB 
LTDA Y= <6. ceo eer a net Gare antes Bae S ICFLIB 
Last Change ..........: = £210/03/90 14:50:39 
Description .......... : RPG Multi-Session example w/DDS (tar 
Source Listing 
100 HARK KAK KAR KKK KEK KERR RRR RRR RRR RRR RRR RRR ER RRR RRR ERR RRR RR RRRERRREREER 
200 H* 
300 H* THIS PROGRAM WILL HANDLE THE REQUEST FOR EITHER A CUSTOMER 
400 H* NUMBER OR AN ITEM NUMBER. THIS IS ACCOMPLISHED BY MAKING 
500 H* THE DATABASE FILE STRUCTURE (KEY LENGTH, KEY POSITION, RECORD 
600 H* LENGTH, RECORD SIZE, ETC.) THE SAME FOR BOTH FILES WITH ONLY 
700 H* THE RECORD CONTENTS DIFFERENT. 
800 H* 
900 H* THIS PROGRAM ENDS WHEN A DETACH REQUEST IS RECEIVED FROM 
1000 H* THE SOURCE PROGRAM. 
1100 H* 
1200 H&K KR KK RR KEK KERR KERR KERR KERR RRR RRR RRR RRR RRR RRR RRR REE REE RRR RRR ERERERE 
H 
1300 FCFILE CF E WORKSTN 
1400 F KINFDS FEEDBK 
1500 F KINFSR *PSSR 
RECORD FORMAT(S): LIBRARY ICFLIB FILE CFILE. 
EXTERNAL FORMAT SNDPART RPG NAME SNDPART 
EXTERNAL FORMAT RCVPART RPG NAME RCVPART 
EXTERNAL FORMAT RCVTRND RPG NAME RCVTRND 
1600 FPFILE IF E K DISK 
RECORD FORMAT(S): LIBRARY ICFLIB FILE PFILE. 
EXTERNAL FORMAT DBREC RPG NAME DBREC 
1700 FQPRINT O- F 132 PRINTER 
1800 * 
AQO0000 INPUT FIELDS FOR RECORD SNDPART FILE CFILE FORMAT SNDPART. 
AQ00001 11 RECTYP 
A000002 2 7 ITEMNO 
A000003 8 137 EDATA 
A000004 138 150 FILL1 
BOOO000 ~=INPUT FIELDS FOR RECORD RCVPART FILE CFILE FORMAT RCVPART. 
BQ00001 1 6 RECID2 
BQ00002 7 86 PARTDS 
BQ00003 87 150 FILL4 
C0Q0000 = INPUT FIELDS FOR RECORD RCVTRND FILE CFILE FORMAT RCVTRND. 
DOO0G@@ ==INPUT FIELDS FOR RECORD DBREC FILE PFILE FORMAT DBREC. 
DO00001 1 1 RECCUS 
DO00002 2 7 DBSEQ 


*NODUMP *NOOPTIMIZE 


get) 


10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 


10/13/87 


10/13/87 
10/14/87 


10/13/87 


10/13/87 
03/20/89 


Figure 11-24 (Part 1 of 5). Target Program Example — RTDMUL (User-Defined Formats) 
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KEKEKK 


D000003 
De00004 
1900 
2000 
2100 
2200 
2300 
2400 
2500 
2600 
2700 
2800 
2900 
3000 
3100 
3200 
3300 
3400 
3500 
3600 
3700 
3800 
3900 
4000 
4100 
4200 
4300 
4400 
4500 
4600 
4700 
4800 
4900 
5000 
5100 
5200 
5300 
5400 
5500 
5600 
5700 
5800 
5900 
6000 
6100 
6200 
6300 
6400 
6500 
6600 
6700 
6800 
6900 
7000 
7100 
7200 
7300 
7400 
7500 
7600 
7700 
7800 
7900 
8000 
8100 
8200 
8300 


8 137 DBDATA 
138 150 DBFILL 
IFEEDBK DS 
*ROUTINE LOC 
*STATUS ERR 
38 45 FMTNM 
273 282 PGMDEV 
401 404 MAJMIN 
401 402 MAJCOD 
I 403 404 MINCOD 
CHAK KKK KKK KKK KK KKK EKER KKK KK KKK ERE KER ERE KKK KKK KEK ERR ERE RRR ERE EE 
C* 
Cx READ THE REQUEST FROM THE SOURCE PROGRAM. INDICATOR 40 
Cx INDICATES RCVTRNRND OCCURRED. INDICATOR 44 INDICATES THAT 
Cx DETACH HAS BEEN RECEIVED. 
C* 
C* INDICATOR 99 WILL BE TURNED ON FOR "I/O ERRORS" THEREBY 
Cx PREVENTING THE RPG DEFAULT ERROR HANDLER FROM BEING CALLED. 
Cx THIS IS NECESSARY TO ALLOW THE PROGRAM TO PROCESS THE ICF 
C* MAJOR/MINOR RETURN CODE. THIS PROGRAM CHECKS FOR ERRORS ON 
Cx EVERY ICF FILE OPERATION. A MAJOR CODE GREATER THAN 03 
Cx INDICATES AN ERROR. 


ee ee 


Cx 

CRA KAA K HARKER KKK KERR KER KKK KEK KKK KKK KK EKER EK KEK EKER KERR ERE 
2 

C READ TAG 

C READ RCVPART 9950 

C MAJCOD CABGT'03' ERROR 

C *IN44 CABEQ'1' END DET RECV? 

C MOVE RECID2 DBSEQ 

C MAJMIN CABEQ'0000' XMIT RCVTRNRND? 
C *IN40 CABEQ'1' XMIT RCVTRNRND? 
is 

C *IN40 DOWEQ'O' RCVTRNRND? 
ic READ RCVTRND 9950 

C MAJCOD CABGT'Q3' ERROR 

C *IN44 CABEQ'1' END DETACH RECV? 
C END 


CRA KKK KKK K KKK KK RRR ERK KEK KKK KKK ERE R ERE RE KKK KKK KER RRR EER EKER EKER RE 
C* 

Cx A REQUEST FROM THE SOURCE PROGRAM RESULTS IN READING A SINGLE 
Cx RECORD CONTAINING THE REQUESTED CUSTOMER OR ORDER NUMBER. THE 
Cx RESPONSE WILL BE RETURNED IN A SINGLE RECORD CONTAINING EITHER 
Cx THE ITEM OR CUSTOMER INFORMATION, DEPENDING ON THE DATABASE 

Cx CONTENT. 

C* 

Cx THE RESPONSE IS SENT TO THE SOURCE PROGRAM BY WRITING TO THE 
Cx ICF FILE USING FORMAT SNDPART. 

C* 


CR KR KRA KK RAKE ERR KER RRR RRR ERR KER ERE RRR ERR ER ERE REE REE ER ER ERE 


C XMIT TAG 

C DBSEQ CHAINPFILE 98 98 IF NOT FD 1 
C MOVE DBSEQ ITEMNO 

C MOVE RECCUS RECTYP RECD FMT ID 


CRRA RRR RK RRR RK KEK KIRK KKK RRR K KKK KKK KKK KKK KIRK KER KERR KER ERE ERR 
C* 

Cx WHEN THE REQUESTED CUSTOMER OR ITEM NUMBER IS NOT FOUND, 

Cx 000000 IS PROPAGATED TO THE KEY FIELD BEFORE THE RESPONSE 

Cx IS SENT BACK TO THE SOURCE PROGRAM. 


C* 

CRRA KKK K KKK KEKE RRR RRR ER RK ERR KER ERE RRR ERE KER ERE RRR ER ER ER ERE REE RRR 
C 98 MOVE '900000' ITEMNO 

Cc MOVELDBDATA EDATA MOVE DATA 

Cc WRITESNDPART DATA W/DET 

Cc MAJCOD CABGT'03' ERROR 

C GOTO READ 


Figure 11-24 (Part 2 of 5). Target Program Example — RTDMUL (User-Defined Formats) 
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2 3 


BOO1 
23 001 
001 
001 
E001 


10/13/87 
10/14/87 
10/14/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
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8400 
8500 
8600 
8700 
8800 
8900 
9000 
9100 
9200 
9300 
9400 
9500 
9600 
9700 
9800 
9900 
10000 
10100 
10200 
10300 
10400 
10500 
10600 
10700 
10800 
10900 
11000 
11100 
11200 
11300 
11400 
11500 
11600 
11700 
11800 
11900 
12000 
12100 
12200 
12300 
12400 
* 6103 
£000000 
£000001 
£000002 
£000003 
E000004 


CR R RARER RRR KKK RRR RK KKK KKK KK KKK KKK KKK KEKE KKK KER KERRIER ERE RRR RE 
C* 

Cx IF ANY ICF FILE ERROR OCCURS, PRINT THE ERROR MESSAGE, 

Cx AND THEN END THE JOB. 


C* 

CHK HRA K HARKER RK RAKE KKK ERK KEK KKK KKK KKK KKK KEKE KEK KEK KERRIER EKER KEK 
*H 

C ERROR TAG 

C EXCPTMMERR 

C END TAG 
6 | 

C SETON LR 

C RETRN 


CRRA KKK K KK KKK KER ERK KKK KKK KEK ERR ERR KKK KKK KKK ERE KERR RRR REKEKEKEKEAE ERE 
C* 

Cx THIS IS THE PROGRAM EXCEPTION/ERROR SUBROUTINE THAT RECEIVES 
Cx CONTROL WHEN AN EXCEPTION OR ERROR OCCURS AFTER AN I/O IS 

Cx ISSUED TO AN ICF PROGRAM DEVICE AND THERE IS A NON-ZERO 

Cx VALUE UPDATED IN THE RPG STATUS FIELD (ERR). THIS ROUTINE 

Cx CHECKS FOR STATUS VALUES THAT RELATE TO AN ICF OPERATION. 

Cx IF THE PROGRAM DEVICE IS ALREADY ACQUIRED, THE EXCEPTION IS 
Cx IGNORED, OTHERWISE THE PROGRAM IS TERMINATED. 

C* 


CRRA KKK KKK K RRR RRR KERR RE RRR ERR KER ERE RRR ERK KER EKER ER ERE ER ERE RERER 


‘ 

C *PSSR BEGSR 

C MOVE ' "RETURN 6 DEFAULT 

C ERR CABEQ01285 ENDPSR ALREADY ACQ? 
C MOVE '*CANCL' RETURN JOB ENDS 

C ENDPSR ENDSRRETURN BACK TO MAIN 
GET TTT TTT TTT TTT TTT TT IT TTT TTT TTT TEE LECT LE CLEC LCC 
OQPRINT E 1 MMERR 

0 21 'ERROR ON ICF 

0 34 'MAJOR/MINOR: ' 

0 MAJCOD 37 

0 38 '/' 

0 MINCOD 40 

0 49 'FORMAT:' 

0 FMTNM 60 

0 69 'PGMDEV:' 

0 PGMDEV 80 


12401 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 


OUTPUT FIELDS FOR RECORD SNDPART FILE 
RECTYP 1 


CFILE FORMAT SNDPART. 
CHAR a 


ITEMNO 7 CHAR 6 

EDATA 137. CHAR 130 

FILL1 150 CHAR 13 

ee ee * END OF SOURCE ** * * * 
Additional Diagnostic Messages 


* 7089 1300 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE CFILE. 
Key Field Information 
PHYSICAL LOGICAL 
FILE/RCD FIELD FIELD ATTRIBUTES 
02 PFILE 
DBREC 
DBSEQ CHAR 6 
Cross Reference 
File and Record References: 
FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 
01 CFILE WORKSTN 1300D 
RCVPART 1300D BO00000 4300 
RCVTRND 1300D C000000 5100 
SNDPART 1300D A000000 8100 E000000 
02 PFILE DISK 1600D 6900 
DBREC 1600D DO00000 
03 QPRINT PRINTER 1700D 11500 12401 


Figure 11-24 (Part 3 of 5). Target Program Example — RTDMUL (User-Defined Formats) 
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10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/14/87 
10/14/87 
10/14/87 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
03/20/89 
10/14/87 
10/14/87 
03/20/89 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 


Field References: 
FIELD 
*IN40 
*IN44 


* 7031 DBFILL 


ERROR 
FEEDBK 
FILL1 
* 7031 FILL4 
FMTNM 
ITEMNO 
* 7031 LOC 
MAJCOD 
MAJMIN 
MINCOD 
MMERR 
* 7031 PARTDS 
PGMDEV 
READ 
RECCUS 
RECID2 
RECTYP 
RETURN 
XMIT 
"*CANCL' 
1g! 
"0000! 
"000000 ' 
193! 
yh 
01285 


ATTR 
A(1) 
A(1) 
BEGSR 
A(130) 
A(13) 
A(6) 
A(130) 
TAG 
ENDSR 
Z(5,0) 
TAG 

DS (404) 
A(13) 
A(64) 
A(8) 
A(6) 
A(8) 
A(2) 
A(4) 
A(2) 
EXCPT 
A(80) 
A(10) 
TAG 
A(1) 
A(6) 
A(1) 
A(6) 
TAG 
LITERAL 
LITERAL 
LITERAL 
LITERAL 
LITERAL 
LITERAL 
LITERAL 
LITERAL 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


*IN 
LR 
OA 
7031 05 
7031 10 


+ + FF F F 


4500 
9500M 
1700D 


4800 
4500 
4300M 
6900M 
4300M 


KKK KK END 0 


* QRG6103 Severity: 


Message 


REFERENCES (M=MODIFIED D=DEFINED) 


4800 
4500 
1300 
DQ00003D 
D000004D 
Dee0002D 
A000003D 
4500 
11100 
2100D 
4400 
1300 
A000004D 
BQ00003D 
2200D 
A000002D 
2000D 
2500D 
2400D 
2600D 
9200 
BQ00002D 
2300D 
4200D 
DQ00001D 
BQ00001D 
A000001D 
11000D 
4700 
11000 
11200 
5000 
4700 
7900 
4400 
4500 
11100 


4800 


12401 


5000 
5300 
5100M 
7900 
5100M 


5000 
5300 
10900D 
8000 


4600M 6900 7000 
8000M E000003D 

5300 9300D 

11300D 

11100 

5200 8200 9100D 
1900D 


E000004D 


12200 
7000M 7900M EQ00002D 


4400 5200 8200 
4700 
12000 
11500 


12400 

8300 

7100 

4600 

7100M E000001D 
11200M =: 11300 


4800 6800D 
5200 8200 
4800 5300 


5000 5300 


F CROSS REFERENCE 


00 Number: 


1 


Summary 


11800 


kK kK KKK 


Message... .: No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 12 
Message... .: The Name or indicator is not referenced. 
* QRG7089 Severity: 00 Number: 1 

Message... .: The RPG provides Separate-Indicator area for 

file. 


KKK KK END 0 


F MESSAGE SUMMARY 


KKK KK 
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Final Summary 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


14 14 0 0 0 0 ) 
Program Source Totals: 
Records ..........: £4124 
Specifications ......: 54 
Table Records .......: 0 
Comments .........: £70 


PRM has been called. 
Program RTDMUL is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**e*e*e* END OF COMPILATION *¥* * * * 


Figure 11-24 (Part 5 of 5). Target Program Example — RTDMUL (User-Defined Formats) 


11-72 —ICF Programming V4R1 


Compiler 


Command Options: 


Program 
Source file 
Source member 


ICFLIB/RTFMUL 
ICFLIB/QICFPUB 
*PGM 


Text not available for message RXT0073 file QRPGMSG. 


IBM AS/400 RPG/400 


Generation options. ......:  *NOLIST *NOXREF *NODUMP *NOOPTIMIZE 
Source listing indentation... :  »*NONE 
SAA flagging. ......... =: + *NOFLAG 
Generation severity level ...: 9 
Print file... ....... . 2 *LIBL/QSYSPRT 
Replace program ........: *YES 
Target release... ..... =. : = *CURRENT 
User profile. .........:  ¥*USER 
Authority.’ 5.00. 8 oA eee BD a8 *LIBCRTAUT 
TOXE eta he crete eS ae ee ees Me 8 *SRCMBRTXT 
Phase trace « 4 eee ee ee 8 *NO 
Intermediate text dump... .. :  “*NONE 
Snap dump .........6..63 *NONE 
Codelist .........+.. +. : + *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member vec we a ek ee RTFMUL 
FAT Gti 52. Sento te, ga eugene au np ale oA Rien QICFPUB 
LT DRANY: sce Sip ence ede Bate eee aE ICFLIB 
Last Change ..........3: 10/03/90 14:52:20 
Description ......... 2 RPG Multi-Session example w/$$FORMAT (target) 
Source Listing 
LOO Hex KAA KR AKER RK KE KKK KERR ERR KEK RRR KERR RRR RRR RRR RRR RR ER RRR REERRR 10/13/87 
200 H* 03/20/89 
300 H* THIS PROGRAM WILL HANDLE THE REQUEST FOR EITHER A CUSTOMER 10/13/87 
400 H* NUMBER OR AN ITEM NUMBER. THIS IS ACCOMPLISHED BY MAKING 10/13/87 
500 H* THE DATABASE FILE STRUCTURE (KEY LENGTH, KEY POSITION, 10/13/87 
600 H* RECORD LENGTH, RECORD SIZE, ETC.) THE SAME FOR BOTH FILES 03/20/89 
700 H* WITH ONLY THE RECORD CONTENTS DIFFERENT. 03/20/89 
800 H* 03/20/89 
900 H* THIS PROGRAM ENDS WHEN A DETACH REQUEST IS RECEIVED FROM 10/13/87 
1000 H* THE REMOTE PROGRAM. 10/13/87 
1100 H* 03/20/89 
1200 Hex xa KK AAR KARR KARR RAE K RRR RR KERR RRR RRR ERR KER ERE RRR ERR KER ERE RERERERE 10/13/87 
H KKKKK 
1300 FCFILE CF F 256 WORKSTN 10/13/87 
1400 F KINFDS FEEDBK 10/13/87 
1500 F KINFSR *PSSR 10/14/87 
1600 FPFILE IF E K DISK 10/13/87 
RECORD FORMAT(S): LIBRARY ICFLIB FILE PFILE. 
EXTERNAL FORMAT DBREC RPG NAME DBREC 
1700 FQPRINT O F 132 PRINTER 10/13/87 
1800 «qj 38 45 FMTNM 03/20/89 
1900 ICFILE NS 99 10/13/87 
2000 I 1 6 RECID2 10/13/87 
2100 I 7 150 PARTDS 10/13/87 
AQ00000 INPUT FIELDS FOR RECORD DBREC FILE PFILE FORMAT DBREC. 
AQ00001 1 1 ~RECCUS 
A000002 2 7 DBSEQ 
A000003 8 137 DBDATA 
A000004 138 150 DBFILL 
2200 IFEEDBK DS 10/13/87 
2300 I *ROUTINE LOC 10/14/87 
2400 I *STATUS ERR 10/14/87 
2500 I 38 45 FMTNM 10/13/87 
2600 I 273 282 PGMDEV 10/13/87 
2700 =I 401 404 MAJMIN 10/13/87 
2800 I 401 402 MAJCOD 10/13/87 
2900 I 403 404 MINCOD 10/13/87 
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3000 
3100 
3200 
3300 
3400 
3500 
3600 
3700 
3800 
3900 
4000 
4100 
4200 
4300 
4400 
4500 
4600 
4700 
4800 
4900 
5000 
5100 
5200 
5300 
5400 
5500 
5600 
5700 
5800 
5900 
6000 
6100 
6200 
6300 
6400 
6500 
6600 
6700 
6800 
6900 
7000 
7100 
7200 
7300 
7400 
7500 
7600 
7700 
7800 
7900 
8000 
8100 
8200 
8300 
8400 
8500 
8600 
8700 
8800 
8900 
9000 
9100 
9200 
9300 
9400 
9500 
9600 
9700 


CR K KKK KAKA KK KKK KER ERK KKK KKK KEKE ERR ERR K KKK ERE KERR RE REKERKEKRAERERE 
C* 

Cx READ THE REQUEST FROM THE SOURCE PROGRAM. INDICATOR 40 

Cx INDICATES RCVTRNRND OCCURRED. INDICATOR 44 INDICATES THAT 
Cx DETACH HAS BEEN RECEIVED. 

C* 

C* INDICATOR 99 WILL BE TURNED ON FOR "I/O ERRORS" THEREBY 

Cx PREVENTING THE RPG DEFAULT ERROR HANDLER FROM BEING CALLED. 
Cx THIS IS NECESSARY TO ALLOW THE PROGRAM TO PROCESS THE ICF 
C* MAJOR/MINOR RETURN CODE. THIS PROGRAM CHECKS FOR ERRORS ON 
Cx EVERY ICF FILE OPERATION. A MAJOR CODE GREATER THAN 03 

Cx INDICATES AN ERROR. 


C* 

CRA KKK KKK KKK KKK KKK EKER KK KKK KEK ERE RRR EKER KKK K KEKE ERR EERE KER RRR ER 
orm 2 | 

C READ TAG 

C READ CFILE 9950 

C MAJCOD CABGT 'Q3' ERROR SESSION ERR 
C MINCOD CABEQ'08' END DETACH RECV? 
C MOVE RECID2 DBSEQ SAVE RECD # 
C MAJMI CABEQ'0000' XMIT RCVTRNRND? 
C MAJMI CABEQ'0300' XMIT RCVTRNRND? 
rm 3 | 

C MINCOD DOWNE'0Q' RCVTRNRND? 
C READ CFILE 9950 

C MAJCOD CABGT 'Q3' ERROR 

C MINCOD CABEQ'08' END DETACH RECV? 
C END 

CRRA KAKA KK KKK KER EKER KEK KKK KEK EERE RR KKK KKK KKK ERE ERR ERE REE AEEEEK 
C* 

Cx A REQUEST FROM THE SOURCE PROGRAM RESULTS IN READING A SINGLE 
Cx RECORD CONTAINING THE REQUESTED CUSTOMER OR ORDER NUMBER. THE 
Cx RESPONSE WILL BE RETURNED IN A SINGLE RECORD CONTAINING EITHER 
Cx THE ITEM OR CUSTOMER INFORMATION, DEPENDING ON THE DATABASE 


Cx CONTENT. 

Cx 

C* THE RESPONSE IS SENT TO THE SOURCE PROGRAM BY WRITING TO THE 
C* ICF FILE USING FORMAT SNDPART. 


C* 

CR R RARER KKK KKK ERK KKK KERR K KKK KKK KKK EKER EKER KERRIER ERE RRR 
c*Q 

C XMIT TAG 

C DBSEQ CHAINPFILE 98 98 IF NOT FD 
C MOVE DBSEQ RECID2 


CR R RARER KKK KKK KERR RK KKK RRR KK KKK KERR EKER KRE KER ERR ERE 
C* 

Cx WHEN THE REQUESTED CUSTOMER OR ITEM NUMBER IS NOT FOUND, 
Cx 000000 IS PROPAGATED TO THE KEY FIELD BEFORE THE RESPONSE 
Cx IS SENT BACK TO THE SOURCE PROGRAM. 


Cx 

CER KARA K HARK ERK RAR KKK KK KR KEK K KER KEK KKK KEK KKK KEKE KER KEKE EER KEK 
C 98 MOVE '000000' RECID2 

C EXCPTSNDITM DATA 

C MAJCOD CABGT'03' ERROR 

C GOTO READ 


CRRA ARK K KERR KK KEK KKK KKK KKK KK KKK KEK KK KEKE KKK KERR KKK ERE 
C* 

Cx IF ANY ICF FILE ERROR OCCURS, PRINT THE ERROR MESSAGE, 

Cx AND THEN END THE JOB. 


C* 

CHK KARA K KARA KAKA KERR KKK KEK K KEK KEK KKK KEK KK EK KEKE KER KEKE EER KEK 
*H 

C ERROR TAG 

C EXCPTMMERR 

C END TAG 

*G 

C SETON LR 

C RETRN 


2 3 


2 3 


Figure 11-25 (Part 2 of 4). Target Program Example — RTFMUL (System-Supplied Formats) 


11-74 


ICF Programming V4R1 


BOO1 
001 
001 
001 

E001 


10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/03/90 
03/20/89 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 
10/13/87 
03/20/89 
10/13/87 
10/13/87 


9800 
9900 
10000 
10100 
10200 
10300 
10400 
10500 
10600 
10700 
10800 
10900 
11000 
11100 
11200 
11300 
11400 
11500 
11600 
11700 
11800 
11900 
12000 
12100 
12200 
12300 
12400 
12500 
12600 
12700 
12800 
12900 
13000 
13100 
13200 
* 6103 


CRRA RK KERR RRR AK KEK KKK KKK KKK KKK KKK KKK KKK KKK KEKE EER KKK ERE RR EK 
C* 

Cx THIS IS THE PROGRAM EXCEPTION/ERROR SUBROUTINE THAT RECEIVES 
Cx CONTROL WHEN AN EXCEPTION OR ERROR OCCURS AFTER AN 1/0 

Cx IS ISSUED TO AN ICF PROGRAM DEVICE AND THERE IS A 

Cx NON-ZERO VALUE UPDATED INTO THE RPG STATUS FIELD (ERR). 

Cx THIS ROUTINE CHECKS FOR STATUS VALUES THAT RELATE TO 

Cx ICF OPERATION. 

Cx IF THE PROGRAM DEVICE IS ALREADY ACQUIRED, THE EXCEPTION IS 
Cx IGNORED, OTHERWISE THE PROGRAM IS TERMINATED. 


C* 

CRRA AKER RRR AK KER KKK KKK KKK KKK KKK KKK KEKE KKK KERR KKK RRR ERR EK 
7 | 

C *PSSR BEGSR 

C MOVE ' "RETURN 6 DEFAULT 

C ERR CABEQ01285 ENDPSR ALREADY ACQ? 
C MOVE '*CANCL' RETURN JOB ENDS 

C ENDPSR ENDSRRETURN BACK TO MAIN 
OQPRINT E 1 MMERR 

0 21 ‘ERROR ON ICF 

0 34 'MAJOR/MINOR: ' 

0 MAJCOD 37 

0 381 f" 

0 MINCOD 40 

0 49 'FORMAT:' 

0 FMTNM 60 

0 69 'PGMDEV:' 

0 PGMDEV 80 

OCFILE E SNDITM 

0 K6 '$$SEND' 

0 4 '0150' 

0 RECCUS 5 

0 RECID2 11 

0 DBDATA 141 

0 DBFILL 154 


13201 OVERFLOW INDICATOR OA ASSIGNED TO FILE QPRINT. 
ee ee * END OF SOURCE ** * * * 
Additional Diagnostic Messages 


* 7089 1300 RPG PROVIDES SEPARATE INDICATOR AREA FOR FILE CFILE. 
Key Field Information 
PHYSICAL LOGICAL 
FILE/RCD FIELD FIELD ATTRIBUTES 
02 PFILE 
DBREC 
DBSEQ CHAR 6 
Cross Reference 
File and Record References: 
FILE/RCD DEV/RCD REFERENCES (D=DEFINED) 
01 CFILE WORKSTN 1300D 1900 4600 5400 12600 
$$SEND 12700 
02 PFILE DISK 1600D 7200 
DBREC 1600D A000000 
03 QPRINT PRINTER 1700D =11600 13201 
Field References: 
FIELD ATTR REFERENCES (M=MODIFIED D=DEFINED) 
*PSSR BEGSR 1300 11100D 
DBDATA A(130) A000003D 13100 
DBFILL A(13) A000004D 13200 
DBSEQ A(6) AQ00002D 4900M 7200 7300 
END TAG 4800 5600 9400D 
ENDPSR ENDSR 11300 11500D 
ERR Z(5,0) 2400D = =11300 
ERROR TAG 4700 5500 8300 9200D 
FEEDBK DS (404) 1300 2200D 
FMTNM A(8) 2500D 12300 
* 7031 LOC A(8) 2300D 
MAJCOD A(2) 2800D 4700 5500 8300 11900 
MAJMIN A(4) 2700D 5000 5100 
MINCOD A(2) 2900D 4800 5300 5600 12100 
MMERR EXCPT 9300 11600 
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10/14/87 
10/14/87 
10/14/87 
10/14/87 
10/03/90 
01/19/88 
01/19/88 
10/03/90 
03/20/89 
03/20/89 
10/14/87 
10/14/87 
03/20/89 
10/14/87 
10/14/87 
10/14/87 
10/14/87 
03/20/89 
10/13/87 
10/03/90 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
10/13/87 
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* 7031 PARTDS A(144) 2100D 
PGMDEV A(10) 2600D 12500 
READ TAG 4500D 8400 
RECCUS A(1) AQ00001D 12900 
RECID2 A(6) 2000D 4900 7300M 8100M 13000 
RETURN A(6) 11200D = 11400M 11500 
SNDITM EXCPT 8200 12600 
XMIT TAG 5000 5100 7100D 
: : LITERAL 11200 
"*CANCL' LITERAL 11400 
‘00! LITERAL 5300 
"0000! LITERAL 5000 
*000000' LITERAL 8100 
‘03! LITERAL 4700 5500 8300 
"0300! LITERAL 5100 
08! LITERAL 4800 5600 
01285 LITERAL 11300 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


LR 9600M 
OA 1700D =: 13201 
* 7031 50 4600M 5400M 
98 7200M 8100 
* 7031 99 1900M 4600M 5400M 
x*x*e*e*e END OF CROSS REFERENCE ** * * * 


Message 
Number: 1 


Summary 


* QRG6103 Severity: 00 


Message... .?: No Overflow Indicator is specified but an 
indicator is assigned to a file and automatic skip to 6 is 
generated. 

* QRG7031 Severity: 00 Number: 4 
Message... . 3: The Name or indicator is not referenced. 
* QRG7089 Severity: 00 Number: 1 
Message... .? The RPG provides Separate-Indicator area for 
file. 
ee *e* * END OF MESSAGE SUMMARY ** * * * 
Final Summary 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 
6 6 0 Q 0 0 ) 
Program Source Totals: 
Records: «6 bos ew eh ee 8 132 
Specifications ......: 62 
Table Records .......: 0 
Comments .........3: 70 


PRM has been called. 
Program RTFMUL is placed in library ICFLIB. 00 highest Error-Severity-Code. 
**e*e*e*e END OF COMPILATION *¥** * * * 


Figure 11-25 (Part 4 of 4). Target Program Example — RTFMUL (System-Supplied Formats) 
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Chapter 12. Tracing Intersystem Communications Function Operations and 


Functions 


You can use the Trace Intersystem Communications Func- 
tion (TRCICF) command to save information about the lan- 
guage operations and communications functions directed to 
an ICF file. The trace information can be collected in the 
current job or in the job being serviced as a result of the 
Start Service Job (STRSRVJOB) command. 


The Start Service Job (STRSRVJOB) command allows you 
to collect trace records for jobs started from other work 
stations or for batch jobs. After the STRSRVJOB command 
has been entered, the TRCICF command must be entered to 
start the trace. 


The End Service Job (ENDSRVJOB) command is used to 
end the service job request. No parameters are used with 
this command. The trace must be stopped before this 
command can be entered. The CL Reference book has 
more information about the STRSRVJOB and ENDSRVJOB 
commands. 


Trace ICF traces all ICF I/O operations that occur in the job 
in which the command was entered. During the time that 
TRCICEF is active, all programs that run in the job are moni- 
tored by TRCICF. TRCICF can be entered within different 
jobs, and the trace for one job runs independently of the 
trace for another job. 


The Trace ICF function can be started, stopped, or ended. 
You can start the Trace ICF function from a system menu, by 
typing the TRCICF command on a command line, or from a 
control language (CL) program within a job. After the trace is 
started, trace records are collected and stored in an internal 
trace storage area. When the trace is stopped, the trace 
records can either be directed to the spooled printer file, 
QPIFTRCF, or sent to a database output file that you specify. 
When the trace is ended, all trace records are deleted. 
Details about starting, stopping, and ending the Trace ICF 
function are discussed in this chapter. 


Starting the Trace 


The Trace ICF (TRCICF) function can be started before 
running a job or after the job is active (as in a remote job). 
You can start TRCICF from a system menu, by typing 
TRCICF *ON on any command line, by adding the command 
to a CL program, or by typing TRCICF on a command line 
and pressing F4 (Prompt). If the latter method is used, an 
initial prompt is displayed for the Trace option setting. If “ON 
is specified and you press the Enter key, the following 
display is shown: 


© Copyright IBM Corp. 1997 


[ Trace ICF (TRCICF) | 


Type choices, press Enter. 


Trace option setting. ..... *ON 
Maximum storage to use. .... 200_ 
Trae Tul. Fo ae nil ahs See te *WRAP *WRAP, *STOPTRC 
User data length. ....... 128 0-4096 


*ON, *OFF, *END 
1-16000 K 


Bottom 


F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display 


F24=More keys 


Trace option setting 
Specify whether collecting trace information is to be 
started, stopped, or ended. 


*ON 
Trace ICF is to be started. This is the 
default value for this prompt. 

*OFF 
Trace ICF is stopped. No other trace infor- 
mation is recorded and the current informa- 
tion is written to the spooled printer file or a 
database file. 

*END 


Trace ICF is ended. All trace information is 
deleted. 


Maximum storage to use 
Specify the maximum amount of storage to use for 
the trace information collected. This prompt is only 
shown if you have selected *ON for the Trace option 
setting prompt. 


200KB 
The number of bytes (1KB equals 1024 
bytes) of maximum storage. This is the 
default value. 


1-16000KB 
The valid range for the number of bytes of 
maximum storage. 


Trace full 
Specify whether new trace records are to replace 
the old trace records or to stop the trace function 
when the maximum storage specified has been 
reached. This prompt is only shown if you have 
selected *ON for the Trace option setting prompt. 
Valid values are: 
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*WRAP 
When the trace storage area is full, new 
trace information is written over the oldest 
information, starting at the beginning of the 
storage area. This is the default value. 


*STOPTRC 
No new trace information is saved when 
the trace storage area is full. You must 
turn the trace off to get the output. 


User data length 
Specify the maximum length of user data to be 
saved for each trace record in the storage area. 
This prompt is only shown if you have selected *ON 
for the Trace option setting prompt. 


128 
The number of bytes for the user data 
length. This is the default value. 

0-4096 
The valid range of bytes for the user data 
length. 


Stopping the Trace 


Trace ICF continues to collect trace records until you stop 
the trace, or until the trace storage area is full. When you 
stop the trace, the trace records that have been created are 
either directed to the spooled printer file, QPIFTRCF, or to a 
database output file that you specify. If the output file speci- 
fied already exists, it must have the same attributes as the 
system-supplied file QAIFTRCF. 


You can stop the trace from a system menu, by typing 
TRCICF *OFF on any command line, by adding the 
command to a CL program, or by typing TRCICF and 
pressing F4 (prompt). If the latter method is used, and you 
specify *OFF for the Trace option setting, you are prompted 
for the OUTPUT parameter. If you specify the *OUTFILE 
option for the Output prompt, the following display is shown: 


(— >) 
Trace ICF (TRCICF) 


Type choices, press Enter. 


Trace option setting. ..... > *OFF *ON, *OFF, *END 
QUEPUES 6 ce Scar Bo eines fein Ses ae an > *QUTFILE *PRINT, *OUTFILE 
Output: TIO) oc ey cd eee ee Name 

Li bray! ¢ snare ye ei Src *LIBL Name, *LIBL, *CURLIB 
Output member options: 

Member to receive output .. . *FIRST Name, *FIRST 


Replace or add records... . *REPLACE *REPLACE, *ADD 


Output 
Specifies whether the trace information is to be 
stored in a spooled file or saved in a database file. 
This display is only shown if *OFF is specified for 
the Trace option setting prompt. Valid values are: 
*PRINT 


The trace information is sent to the spooled 
file QPIFTRCF in the output queue associ- 
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ated with the job being traced. The 
spooled file can be viewed or printed. 
Refer to Figure 12-1 on page 12-3 for an 
example of the spooled trace records. This 
is the default value. 


*OUTFILE 
The trace records are to be directed to a 
database file. Refer to “Trace Records 
Sent to a Database File” on page 12-4 for 
a description of trace records directed to a 
database file. The *OUTFILE value for the 
Output prompt is only valid if a value is 
specified for the Output file prompt. 


Output file 
Specifies the name of the database file to which the 
trace records are to be sent. This prompt is only 
shown if you have selected *OFF for the Trace 
option setting prompt and *OUTFILE for the Output 
prompt. If the file does not exist, the system 
creates a new database file with the specified name 
in the library to which the file is to be added. The 
new file has the same attributes as the system- 
supplied file QAIFTRCF. If the file already exists, it 
must have the same attributes as the system- 
supplied file QAIFTRCF. Possible library values 


are: 
Name 
The name of the library where the file is 
located. 
*LIBL 


The file is located in the library list. 


*CURLIB 
The file is located in the current library for 
the job. If no current library entry exists in 
the library list, the library QGPL is used. 


Output member options 
Specifies the name of the file member that is to 
receive the trace information. This prompt is only 
shown if you have selected *OFF for the Trace 
option setting prompt and *OUTFILE for the Output 
prompt. If the output file is to be created by the 
system, an output member is also created and given 
the name specified in the Member to receive output 
prompt. If *FIRST is specified for the Member to 
receive output prompt, a member is created and 
given the name specified in the output file. If the 
output file exists, but the output member does not, a 
member with the specified name is created. The 
options for the Output member options prompt are: 


Member to receive output 
Type the name of the member to receive 
the output. Valid values are: 


*FIRST 
The first member in the output file 
receives the trace information. 
This is the default. 


Name 


The specified member receives 
the trace information. 


Replace or add records 


The trace information is either added to the 


file or replaces existing tra 
Valid values are: 


*REPLACE 


ce information. 


New trace information replaces 


what is already in 


the file member. 


This is the default. 


Function Codes = Meaning 
ACQ Acquire 
AWT Allow-Write 
CFM Confirm 
CLS Close File Prior to REL or EOS 
CNI Cancel-Invite 
CNL Cancel 
CTL Control-Data 
DET Detach 
EGP End-of-Group 
EOA End-of-Session-Abnormal 
EOS End-of-Session 
ERR Error: Function Not Valid 
EVK Evoke 
FAL Fall 
FMH Function-Management-Header 
FMT Format -Name 
FRC Force-Data 
GTA Get-Attributes 
INV Invite 
NRP Negative-Response 
CPN Open with Acquire-Program-Devi 
PRC Prepare-to-Commit 
RCF Respond-to-Confirm 
RCV Receive 
REL Release 
RFI Read-From-Invited-Program-Devi 
RLB Rollback 
RST Restore 
RWT Request-to-Write 
SDV Subdevice-Selection 
SND Send 
SPD Suspend 
TKC Take-Commit 
TMR Timer 
TNS Transaction-Sync-Level 
TRN Turn-Around 
BA Job DSP10 Elser... :  QUSER 
EoProgram . . . . : ICFTEST /ICFMAIN 
Eh Program By Record Return 
Device Format Code Fun 
DEV1 0000 ACQ 
DEV1 EVOKENOV 0000 EVK 
DEV1 NOVARLEN 0001 SND 
DATA: 
THIS IS A PUT WITH INVITE. 
DEV1 NOVARLEN 0308 RCV 
DEV1 EVOKENOV 0000 EVK 
DEV1 NOVARLEN 0001 SND 
DATA: 
THIS IS ANOTHER PUT WITH INVITE. 
DEV1 NOVARLEN 0308 RCV 
DEV1 0000 EOS 
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Figure 12-1. Spooled Trace Records 


ce 


ces 


Eq umber. . 
Ei Program File 
HOpened File .. 


Trace Records Sent to a Spooled File 


*ADD 


New trace information is 
appended to the end of data 
already in the file member. 


When you select *OFF for the Trace option setting prompt 


and press F4, you are presented with the option on the 


Output prompt to send the trace records to a spooled file 


(*“PRINT) or to a database file ("OUTFILE). The default 


value is *PRINT. If you choose the *PRINT value for the 
Output prompt, the trace information is sent to the spooled 


file QPIFTRCF. Figure 12-1 shows the format of the 


spooled trace records. 


00626 


Response 


ction Indicator 
» INV 

DET 
» INV 

DET 


END OF LISTI 


NG 


ICFTEST /ICFTSTCF 
ICFLIB /ICFTSTITF 
Data 
Length 
0 
0 
BO 


ooo 


oo 
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Remote 
Location 
Chicago 
Chicago 
Chicago 


Chicago 
Chicago 
Chicago 


Chicago 
Chicago 


Time 


15:37: 
15:37: 
15:37: 


15:37: 
15:38: 
15:38: 


15:38: 
15:40: 
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Eq Table of Function Codes 
The first page of the spooled trace records is a table 
of the function codes used for each ICF operation. 
The function code is printed in the Function and 
Response Indicator columns. 


Notes: 


1. The suspend (SPD) and restore (RST) function 
codes are used in the System/36 environment. 
These function codes are part of the read- 
under-format (RUF) support. If two programs 
using the RUF support do not run in the same 
job, then the Trace ICF function does not trace 
both programs unless Trace ICF is started for 
both jobs. 


2. The function code OPN indicates that the 
program opened a file that automatically 
acquired a program device. CLS indicates that 
the program closed the file prior to releasing or 
ending the session. 


a Job 


Name of the job in which your program is running. 


User 
The user identification (User ID) used to start the 
job (either the user ID used to sign on the work 
station or the user ID received on the program start 
request). 


EJ Number 
The number assigned to the job step when your 
program started. 


EJ Program 
Name of the library where the program resides, and 
the name of the program that issued the operation 
that is being traced. 


J Program File 
Name of the library where the ICF file named in the 
program resides, and the name of the ICF file 
named in the program. 


Opened File 
Name of the library where the ICF file opened by 
your program resides, and the name of the ICF file 
opened by your program. 


Note: If you used the OVRICFF command to tem- 
porarily override the file named in the program, the 
name specified for the Opened File will be different 
from the Program File name. 


EJ Program Device 
Name assigned to the session to which the lan- 
guage operation or communications function was 
directed. This is the name specified in the Add ICF 
Program Device Entry (ADDICFDEVE) or Override 
ICF Program Device Entry (OVRICFDEVE) com- 
mands. 


EJ Record Format 
Name of the record format used when the commu- 
nications function is issued. The record format can 
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either be a user-defined data description specifica- 
tion (DDS) or a system-supplied format. 


Return Code 
The major and minor return code issued to indicate 
the success or failure of each operation. 


Function 
The function code assigned to represent the lan- 
guage operation or communications function issued 
by the program. Only operations associated with 
your ICF sessions are traced. File open and close 
operations are not traced except when a program 
device is acquired or released as a result of an 
open or close operation. 


Response Indicator 
The function code assigned to represent the DDS 
response indicator that indicates status information 
about the input operation. 


Data Length 
Length of data sent or received by the program. If 
the function indicates a send and receive operation, 
then this field represents the length of data received 
by the program. 


Remote Location 
Name of the remote location with which a commu- 
nication session is established. 


Time 
Time that the language operation or communication 
function was completed by the communications 
type. The time is displayed in hours, minutes, 
seconds, and milliseconds. 


Data 
The data sent or received by the program. The 
amount of data traced depends on the value speci- 
fied for the User data length prompt (DTALEN 
parameter) of the TRCICF command. If the function 
indicates a send and receive operation, then the 
data received by your program is shown. 


Trace Records Sent to a Database File 


When you select *OFF for the Trace option setting, you are 
presented with the option either to send the trace records to 
a spooled file (“PRINT) or send the records to a database file 
(*OUTFILE). If you choose the *OUTFILE value for the 
Output prompt, the trace information is sent to the database 
file that you specify. If you specify a file that already exists, 
it must match the attributes of the system-supplied file 
QAIFTRCF. 


The following example shows the layout of the trace records 
sent to a database file. The database file has a fixed record 
length of 4337 decimal bytes. The record format name is 
QIFTRC. Each record in the file contains all the information 
related to the language operation or communications func- 
tion, as well as the length of data traced. The length of data 
traced is less than or equal to the value specified on the 
User data length prompt (the DTALEN parameter) of the 


TRCICF command. Database files contain much of the 
same information that is contained in spooled files. Data- 
base files also contain the century and system name. For 
the 20th century Century would be 0, and for the 21st 
century Century would be 1, and so on. Date is in the 
YYMMDD format. 


Note: If you want to use QIFTRC as an externally described 
file in your program, use IFDTL2 rather than IFDTLN for 
correct size definition of the data length. 


Ax* 

Ax TRACE ICF OUTFILE RECORD FORMAT FOR TRCICF 
Ax* 

A R QIFTRC TEXT('Trace ICF record') 


IFJOB 10 COLHDG('Job' ‘name') 
TEXT('Name of job') 
IFUSER 10 COLHDG('User' 'name') 
TEXT('Name of user') 


IFNBR 6 COLHDG('Job' 'number') 
TEXT('Number of job') 

IFPGM 10 COLHDG('Program' 'name') 
TEXT('Name of program’) 

IFLIB 10 COLHDG('Library' 'name') 


TEXT('Programs library') 

IFPGMF 10 COLHDG('Program' 'file''name') 
TEXT('Program file') 

IFPGML 10 COLHDG('Program' 'file' 'library') 
TEXT('Program files library') 
IFOPNF 10 COLHDG('Opened' 'file' 'name') 
TEXT('Opened ICF file’) 

IFOPNL 10 COLHDG('Opened' 'file' 'library') 
TEXT('Opened files library') 
IFPGDV 10 COLHDG('Program' 'device') 
TEXT('Program device') 

IFRCFM 10 COLHDG('Record' 'format') 
TEXT('Record format') 

IFMJMN 4 COLHDG('Return' 'code') 
TEXT('Return code') 
COLHDG('Function' 'code') 
TEXT('Function code') 

IFRSPI 36 COLHDG('Response' ‘indicator') 
TEXT('Response indicator') 


IFOPCD 48 


IFDTLN 2B COLHDG('Data' 'length') 
TEXT('Data length') 

IFRLOC 8 COLHDG('Remote' 'location') 
TEXT('Remote location') 

IFTIME 9S © COLHDG('Time') 
TEXT('Time of entry') 

IFDTTR 4B COLHDG('Traced' 'data' 'length') 
TEXT('Traced data length') 

IFCENT 1 COLHDG('Century') 
TEXT('Century of entry') 

IFDATE 6 COLHDG('Date') 
TEXT('Date of entry') 

IFSYS 8 COLHDG('System' 'name') 
TEXT('System name') 

IFDTL2 5B —- COLHDG('Data' 'length') 
TEXT('Data length’) 

IFRES 7 COLHDG('Reserved') 
TEXT('Reserved') 

IFDATA 4096 COLHDG('Data') 


rPrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrre 


TEXT('Data') 


[ Trace ICF (TRCICF) ) 


Type choices, press Enter. 


Trace option setting. ..... *OFF *ON, *OFF, *END 


Additional Considerations 


Trace ICF traces only those operations that are associated 
with your ICF sessions. For example, ICF file open and 
close operations are not traced except when a program 
device is acquired or released as a result of an open or close 
operation. The following restrictions apply to Trace ICF 
traces: 


e When an open of an ICF file is issued without implicit 
acquire of the program device, the explicit acquire of the 
program device (ACQ) will be traced and not the open 
(OPN) operation. 


e¢ An open of an ICF file with implicit acquire of the 
program device is traced as an open operation (OPN). 


e When the close of an ICF file is preceded with an end of 
session (EOS), the end of session is traced but not the 
close (CLS). 


e When the close of an ICF file is preceded by a release 
operation (REL), the release operation is traced but not 
the close operation (CLS). 


e When a close of an ICF file is not preceded by an EOS 
or release operation, it is traced as a close (CLS) opera- 
tion. 


e When receiving program initialization parameters (sent 
by means of an evoke operation) in the System/36 envi- 
ronment with a read operation, the Data length field in 
the trace output will be 0, even if data was actually 
received by your program. 


e When using BSCEL with data compression, the actual 
length of the data received on an input operation is not 
known by the system after decompression. The traced 
data length will be 0 and the traced data will not appear 
in the trace record, even if data was actually received by 
the program. 


Ending the Trace 


You can end TRCICF from a system menu, by typing the 
TRCICF *END command on any command line, by adding 
the command to a CL program, or by typing TRCICF and 
pressing F4 to show the Trace option setting prompt, shown 
following. Type “END and press the Enter key. This causes 
Trace ICF to end and all trace records to be deleted. 


Displaying Communications Status 


You can obtain current status information about operations 
and functions directed to an ICF file for all active (acquired) 
sessions within a job by using the Display Job (DSPJOB) or 
Work with Job (WRKJOB) commands. Choose option 17, 
Display communications status, from a Display Job or Work 
with Job display. You can also access this information from 
the Work with Active Jobs (WRKACTJOB) display. Refer to 
the Communications Management book for more information. 
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Appendix A. Language Operations, Data Description Specifications 
Keywords, and System-Supplied Formats 


This appendix contains charts that show the following: 


e All valid language operations supported by intersystem 
communications function (ICF) 


e All valid operations for each programming language that 
supports ICF (ILE C, ILE COBOL, FORTRAN/400, and 
ILE RPG programming languages) 


¢ Data description specifications (DDS) processing 
keywords supported by communications types 


e System-supplied formats supported by communications 
types 


Language Operations 


Figure A-1 describes the language operations supported by 
ICF. 


Figure A-1. Language Operations 


ICF Operations Description 


Open Opens the ICF file. 


Acquire Establishes a session between the applica- 


tion and the remote location. 


Figure A-1. Language Operations 


ICF Operations Description 


Get attributes Used to determine the status of the session. 
Read Obtains data from a specific session. 


Read-from- Obtains data from any session that has 


invited- responded to an invite function. 

program-devices 

Write Passes data records from the issuing 
program to the other program in the trans- 
action. 

Write/Read Allows a write operation followed by a read 


operation. Valid for ILE C and ILE RPG 
programming languages. 


Release 
Close Closes the ICF file. 


Attempts to end a session. 


Figure A-2 shows all the valid communications operations for 
each programming language that supports ICF (ILE C, ILE 
COBOL, and ILE RPG programming languages). 


Note: When specifying a format name, program device 
name, or program-to-system parameters in your program, 
always use uppercase characters. 


Figure A-2. Language Operations 


ILE COBOL/400 Pro- 


ILE RPG/400 Opera- FORTRAN/400 State- 


ICF Operation ILE C Function! cedure Statement tion ment 

Open fopen, _Ropen OPEN OPEN OPEN 
Acquire _Racquire ACQUIRE ACQ Not supported2 
Get-attributes _Rdevatr ACCEPT POST Not supported 
Read fread, _Rreadn READ READ READ 
Read-from- _Rreadindv READ3 READ3 Not supported 
invited-program- 

devices 

Write fwrite, _Rwrite WRITE WRITE WRITE 
Write/Read _Rwriterd Not supported EXFMT Not supported 
Release _Rrelease DROP REL Not supported 
Close fclose, _Rclose CLOSE CLOSE CLOSE 


1 ILE C functions and statements are case sensitive. 


2 To acquire a program device using the FORTRAN/400 language, you must specify the program device on the ACQPGMDEV parameter on 
the CRTICFF, CHGICFF, or OVRICFF commands. The program device will then be implicitly acquired when the ICF file is opened. 


3 A read operation can be directed either to a specific program device or to any invited program device. The support provided by the 
compiler you are using determines whether to issue an ICF read or read-from-invited-program-devices operation, based on the format of the 
read operation. For example, if a read operation is issued with a format or terminal specified, the read operation is interpreted as an ICF 
read operation. Refer to the appropriate language manual for more information. 
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DDS Keyword Support 


Figure A-3 on page A-2 defines the communications pro- 
cessing control DDS keywords supported for the ICF file, and 
the communications type that supports these keywords. 


Note: DDS keywords supported by APPC apply to APPC 


over TCP/IP, as well. 


Figure A-3 (Page 1 of 4). Processing Control DDS Keywords 


DDS Keyword APPC SNUF 


Async 


Intra- 
system 


Finance 


Retail 


ALWWRT2 

The record currently being 

written ends a transmission. x Xx 
The program goes to 

receive state. 


CANCEL 
Cancels a group of records Xx 
that has just been sent. 


CNLINVITE 
Cancels any valid invite X 
issued by your program. 


CONFIRM2 

Requests that the remote 
program confirm receiving 
data. 


x3 


CTLDTA2 

Informs the remote program 
that control data is being 
sent. 


DETACH 

Informs the remote program 
that the sending program is 
ending the transaction. 


x1 


DFREVOKE2 

Delays an evoke request 

until either the output buffer x 
is full or the output buffer is 

flushed. 


ENDGRP 
Indicates the end of a user- Xx 
defined group of records. 


EOS 
Used to specify an end-of- x Xx 
session function. 


EVOKE 
Starts a program on the Xx X 
remote system. 


FAIL 
Sends a fail indication to Xx X 
the remote system. 


FMH 

Informs the remote program 

that a function- X 
management-header (FMH) 

is being sent. 


x1 
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Figure A-3 (Page 2 of 4). Processing Control DDS Keywords 


DDS Keyword 


APPC 


SNUF 


BSCEL 


Intra- 
Async system Finance Retail 


FMTNAME2 

Specifies that the format 
name should be sent on 
output operations. 


FRCDTA2 

Immediately sends commu- 
nications data currently in 
the buffer, without waiting 
for the buffer to become 
full. 


INVITE 
Schedules an invite. 


NEGRSP 

Informs the remote system 
that the data received is not 
valid. 


PRPCMT 

Indicates that the remote 
program is preparing for a 
synchronization point. 


RCVCANCEL2 

Indicates that the remote 
program sent a cancel 
request. 


RCVCONFIRM2 

Indicates that the remote 
program is requesting a 
confirmation of transaction 
activity. 


RCVCTLDTA2 
Indicates that control data 
has been received. 


RCVDETACH2 

Indicates that the remote 
program has ended the 
transaction. 


RCVENDGRP2 

Indicates the end of a user- 
defined group of records 
sent to the program. 


RCVFAIL2 
Indicates that the remote 
program issued a fail. 


RCVFMH2 

Indicates to the program 
that FMH data has been 
received. 


RCVNEGRSP2 

Indicates that the remote 
program issued a negative- 
response request. 


RCVROLLB 
Indicates if a rollback oper- 
ation has been received. 
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. Processing Control DDS Keywords 


DDS Keyword 


APPC 


SNUF 


BSCEL 


Async 


Intra- 
system 


Finance 


Retail 


RCVTKCMT 
Indicates if a take-commit 
request has been received. 


X 


RCVTRNRND2 
Indicates that the program 
is now in send state. 


RECID2 

Used to allow the data 
content to identify the 
record format to use to 
receive the data. 


RQSWRT 

Specifies that the program 
is requesting permission to 
write. 


RSPCONFIRM2 

Sends a positive response 
to a received confirm 
request. 


SECURITY 

Includes security informa- 
tion needed to start a 
program on the remote 
system. 


SUBDEV2 

Specifies the subdevice to 
which output should be 
directed (for example, 
printer, punch, and so on). 


SYNLVL2 
Indicates the synchroniza- 
tion level of the program. 


TIMER 

Allows the user to specify 
an interval of time to wait 
before a read-from-invited- 
program-devices operation 
receives a timer-expired 
return code. 


TNSSYNLVL 

Specifies the transaction 
synchronization level that is 
performed while issuing a 
write operation. 


VARBUFMGT2: 4 

Allows the user to send or 
receive multiple or partial 
records, rather than just 
one record, by using one 
record format per write or 
read operation. 
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Figure A-3 (Page 4 of 4). Processing Control DDS Keywords 


Intra- 
DDS Keyword APPC SNUF BSCEL Async system Finance Retail 
VARLEN 
Specifies the length of the Xx Xx Xx Xx X X x 


data record sent with each 
write operation. 


1 Use of this keyword is restricted. Refer to the Asynchronous Communications Programming book for more details. 
These DDS keywords do not have system-supplied format equivalents. 
These keywords are not valid for the 3694 controller. Refer to the Finance Communications Programming book for details. 


r wo DD 


Use of this keyword is restricted. Refer to the APPC Programming book for more details. 
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System-Supplied Format Support 


Figure A-4 defines the system-supplied formats supported 
for ICF, and shows the communications types that supports 


these formats. 


Note: System-supplied formats that apply to APPC also 
apply to APPC over TCP/IP. 


Figure A-4. System-Supplied Format Support 


Operation APPC SNUF BSCEL Async ma: Finance Retail 
system 

$$CANL 1 
Cancel with invite a Ks ss “s 
$$CANLNI x x si y 
Cancel 
SPCNEINY Xx Xx x x x x 
Cancel invite 
$SEOS : x x x x x x x 
End of session 
$$EVOK 
Evoke with invite m x - x ss : 
$$EVOKET 
Evoke with detach ‘ “a - as ‘ s 
SOE VORNI Xx x x x x x 
Evoke 
SSF AIL x x x x x x 
Fail 
$$NRSP Negative Xx Xx X Xx 
response with invite 
$$NRSPNI Xx X X X 
Negative response 
$$POSRSP 

af x 
Positive response 
$$RCD 
Request write with Xx x x X 
invite 
$$SEND 
Send with invite or x x x x X xX Xx 
invite 
$$SENDE 
Send with end of x x xX X X 
group 
$$SENDET 
Send with detach . i s ‘ x 
$$SENDFM 
Send FMH with x x x x 
invite 
$$SENDNF 
Send FMH % ‘: ‘ ‘ . 
$$SENDNI X Xx x Xx x % X 
Send 
ao TIMER x x x x x x x 
Timer 


1 These keywords are not valid for the 3694 controller. Refer to the Finance Communications Programming book for more information. 
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Appendix B. Communications Error Handling 


This appendix describes programming considerations for ICF communications error recovery. 
It includes information on: 


e System error classifications 


e« System messages sent on communications errors, and related file error handling in the 
affected job 


e Major/minor return codes and descriptions 


e Error reason codes for failed program start requests 


System Error Classification 


The system divides communications error conditions into several classifications and pro- 
cesses them according to those classifications. The system automatically tries recovery for 
many of these errors without notification to the using program. In some cases, messages 
indicating error recovery is in progress are issued to the system operator message queue 
(QSYSOPR), to the job log, and to other queues specified during device configuration. 
When the system retry limits specified in configuration objects are exceeded, a message is 
sent to these queues and any jobs currently using the failing line, controller, or device. 


Some errors, such as an application program violation of a communications protocol, do not 
cause messages to be sent to system message queues, but are reported to the affected 
program. 


It is recommended that all communications programs examine return codes after each oper- 
ation to detect error conditions and other normal conditions, such as receipt of the detach 
indication from the remote system. Although many error conditions are reported to the 
affected job through messages, the primary method for a program to detect these conditions 
is through return codes and the open feedback and input/output (I/O) feedback areas. 


For a complete description of error classifications and system-provided recovery support, see 
the Communications Management book. 


System Messages 


Some errors can occur that do not affect your program. For example, the varying on of a 
communications line may fail before starting any programs that use devices on the failed 
line. 


Errors that affect your program can occur: 


e When a file is opened 

¢ During I/O operations to the file 

e When a program device is acquired or released 
e When the file is closed 


When you encounter errors that can affect the running of a program, a system message is 
sent to the program message queue of the program using the file. 
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Error messages are divided into the following message types: 


e Notify 

¢ Status 

e Diagnostic 
e Escape 


See the CL Programming book for more information about the message types. 


Figure B-1 is a summary of the messages, by operation, that can be issued. 


Figure B-1. File Error Message Identifier Groups 


Operation Message Type Message Identifiers 

Open Diagnostic and status CPF4001 through CPF40FF 

Open Escapes that make the file CPF4101 through CPF43FF 
unusable 

Close Diagnostic and status CPF4401 through CPF44FF 

Close Escapes that make the file CPF4501 through CPF46FF 
unusable 

Input/Output, Notify with a default reply CPF4701 through CPF48FF 

Acquire, and of cancel, status, and escapes and 

Release that do not make the file or CPF5001 through CPF50FF 
program device unusable 

Input/Output, Notify with a default reply CPF4901 through CPF49FF 

Acquire, and of ignore 

Release 

Input/Output, Escapes that make the file CPF5101 through CPF53FF 

Acquire, and or program device unusable and 

Release CPF5501 through CPF56FF 


These messages are logged in the job log, and the error is communicated to the program 
through language status codes and an ICF major/minor return code in the I/O feedback area 


of the file. 


Some conditions are considered normal application exceptions and do not cause job mes- 
sages. As a result, file error handling for high-level languages is not called. You may need 
to examine the I/O feedback area for major/minor return codes or other device-specific infor- 
mation. You can detect some conditions by using data description specifications (DDS) 


response keywords. 


User Program Error Detection 
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All user programs should detect error conditions and determine appropriate error processing. 
Review all major/minor return codes described in this chapter, and in the programming book 


for the communications type you are using, to determine what processing to do. 


Permanent errors can cause the session, your program, or both to end. A program can try 
to recover from errors without ending. The operation you use and the major code you 


receive determine how your program recovers from the errors. 


In general, you recover from an open operation that fails as follows: 


¢ Close the file 
¢ Correct the problem 
e Issue the open operation again 


An acquire failure is handled as follows: 


¢ Correct the problem 
e Issue the acquire operation again 


You can resume communications for most I/O operations that encounter session errors and 
complete with a major return code of 81 by reacquiring the program device associated with 
the session. For input/output operations that encounter system or file errors completed with 
a major return code of 80, you may or may not need to close and reopen the file to resume 
communications. In some cases, depending on the cause of the error, the device must be 
varied off, then on again, to remedy the problem. Reacquiring the session that failed may 
also allow you to resume communications. To determine specific error recovery procedures, 
check each major/minor return code description in the programming book for the commu- 
nications type you are using. 


If an I/O operation completes with an exception or a nonpermanent error (04, 08, 11, 34, and 
83 majors), then the session is still intact and the program can recover, based on the action 
described for the major/minor return code. 


A release failure can be handled in one of two ways. If you want to end the session grace- 
fully, correct the problem as indicated by the return code, and issue the release operation 
again. For example, if the release operation completes with an 832F, issue a detach 
request, and then issue the release again. If you want to force the session to end, issue an 
end-of-session function. 


If a close operation fails, issue the close again. A second close is always successful. 


The ICF file is implicitly closed when the job ends, if the job ends without recovering from a 
failure. 


Control Language (CL) Commands for Determining Configuration Status 


The Work with Configuration Status (WRKCFGSTS) command provides line, controller, 
device, and mode status for communications on your AS/400 system. Information provided 
by this command can help you determine the status of your devices and sessions in order to 
determine error recovery options. The Retrieve Configuration Status (RTVCFGSTS) 
command is also available to determine line, controller, and device status. See the Commu- 
nications Management book for more information on configuration status. 


Major/Minor Return Codes 
This section contains: 


e Return code tables that identify all communications types and the return codes that are 
valid for each. This summary table is useful when you want to make changes to a 
program so you can use it with a different communications type. 


¢ Summary descriptions of all major and minor return codes for all communications types. 
These return codes are set in the I/O feedback area of the ICF file, and report the results of 
each I/O operation issued by your application program. Your program should check the 


return code and act accordingly. Refer to your high-level language manual for more informa- 
tion on how to access these return codes. 


Each return code is a 4-digit hexadecimal value. The first two digits contain the major code, 
and the last two digits contain the minor code. 
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Notes: 


1. 


In the return code descriptions, your program refers to the AS/400 application program 
that issues the operation and receives a return code from ICF. The target program 
refers to the application program on the remote system with which your program is com- 
municating through ICF. 


Each communications programming book provides detailed information about every 
return code for the communications type and the recovery actions that should be taken. 


Certain return codes describe the turnaround indication, which is not applicable to asyn- 
chronous, retail and finance communications. Also, not all return codes have the same 
meaning for all communications types. 


Return codes that are used only by applications running in the System/36 environment 


are not included in this book. See the Concepts and Programmer's Guide for the 
System/36 Environment, SC41-9663, for information about System/36 environment 
return codes. 


Major Code 00 


B-4 
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A major return code 00 indicates that the operation completed successfully. 


Description 


The operation issued by your program completed successfully. Your program may have 
sent or received some data, or may have received a message from the remote system. 


Note: Error codes for APPC also apply to APPC over TCP/IP. 


Figure B-2 (Page 1 of 2). Major Code 00 


Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0000 X X X Xx x X X 
0001 xX Xx Xx x X Xx 
0002 Xx 
0003 X xX X X 
0004 X X X 
0005 Xx X X 
0006 X 
0007 X X Xx X Xx 
0008 X X Xx X 
000C X X 
0010 Xx X xX X 
0011 X 
0013 X 
0014 X x 
0015 X Xx 
0016 X 
0017 Xx 
0018 X 
001C X X 
001D xX 
0020 
0021 X X 
0023 X 
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Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0025 X 
0027 X 
0028 Xx X 
0030 X 
0031 Xx X 
0033 Xx 
0035 X 
0037 X 
0038 Xx X 
0042 X 
0044 x x 
0045 xX Xx 
0046 Xx 
0047 Xx 
0054 Xx 
Code Description 
0000 Turnaround or end-of-transmission indication and data received on successful 
input operation, or an output operation was successful. 
0001 Successful input operation or write operation with invite. A turnaround or end-of- 
transmission indication was not received. 
0002 Control-data indication received with program start request. 
0003 End-of-group indication received on successful input operation. 
0004 Function-management-header or control-data indication and turnaround indi- 
cation received on successful input operation; or, a PAD message received from 
a remote PAD. 
0005 Function-management-header or control-data indication received on a successful 
input operation. 
0006 Control-data and turnaround indications received with program start request. 
0007 Function-management-header and end-of-group indications received on suc- 
cessful input operation. 
0008 Detach indication received on successful input operation. 
000C Function-management-header or control-data indication received, and detach 
indication received, on a successful input operation. 
0010 Request-to-write, reverse-interrupt (RVI), or request-to-change-direction received 
on successful output operation. 
0011 Control-data and detach indications received with program start request. 
0013 Control-data and turnaround indications received with program start request. In 
addition, the remote system requested confirmation. 
0014 Turnaround indication received on successful input operation. In addition, the 
remote system requested confirmation. 
0015 Remote system requested confirmation on successful input operation. The local 


application program continues to receive data. 
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0016 


0017 


0018 


001C 


001D 


0020 


0021 
0023 
0025 
0027 


0028 
0030 


0031 


0033 
0035 


0037 


0038 


0042 


0044 


0045 


0046 


0047 


0054 


Parity error or stop bit error (framing) or both received on successful input opera- 
tion. 


End-of-group indication received on successful input operation. In addition, the 
remote system requested confirmation. 


Control-data indication received with program start request. In addition, the 
remote system requested confirmation. 


Detach indication received on successful input operation. In addition, the remote 
system requested confirmation. 


Control-data and detach indications received with program start request. In addi- 
tion, the remote system requested confirmation. 


System message and turnaround or end-of-transmission indication received on a 
successful input operation. 


System message received on successful input operation. Continue to receive. 
System message with end-of-group indication received. 
Function-management-header indication received with system message. 


System message received with function-management-header and end-of-group 
indications. 


System message and detach indication received on successful input operation. 


Truncated system message and turnaround or end-of-transmission indication 
received on successful input operation. 


Truncated system message received on successful input operation. Continue to 
receive. 


Truncated system message received with end-of-group indication. 


Truncated system message received with function-management-header indi- 
cation. 


Truncated system message received with function-management-header and end- 
of-group indications. 

Truncated system message and detach indication received on successful input 
operation. 

Some data was lost on successful input operation. 


Function-management-header or control-data indication received, and turnaround 
indication received, on a successful input operation. In addition, the remote 
system requested confirmation. 


Function-management-header or control-data indication received on a successful 
input operation. In addition, the remote system requested confirmation. 


Control-data and detach indications received on a successful input operation. In 
addition, the remote system requested confirmation. 


Function-management-header and end-of-group indications received on suc- 
cessful input operation. In addition, the remote system requested confirmation. 


Rollback is required. The transaction program (TP) has entered the rollback- 
required state. 


Major Code 02 


The major return code 02 indicates that the input operation completed successfully, but your 
job is being ended (controlled). 
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Description 


The input operation issued by your program completed successfully. Your program may 
have received some data or a message from the remote system. However, your job is being 
ended (controlled). 


Code 


APPC 


Asynchro- 
nous 


Figure B-3 (Page 1 of 2). Major Code 02 


BSCEL 


Finance 


Intra- 
system 


Retail 


SNUF 
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0216 
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Figure B-3 (Page 2 of 2). Major Code 02 


Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0259 x 
Code Description 
0200 Ona successful input operation, a turnaround indication or data that is the begin- 


0201 


0202 


0203 


0204 


0205 


0206 


0207 


0208 


020C 


0211 


0213 


0214 


0215 


0216 


0217 


0218 


021C 


021D 


0220 


ning or middle record of a group of records was received. In addition, a job ended 
(controlled) indication was received. 


Data with job ended (controlled) indication received on a successful input operation. 
A turnaround indication was not received. Continue to receive. 


Control-data indication received with job ended (controlled) indication on program 
start request. 


End-of-group indication received with job ended (controlled) indication on successful 
input operation. 


Function-management-header or control-data indication and turnaround indication, 
or a PAD message from a remote PAD, received with job ended (controlled) indi- 
cation on a successful input operation. 


Function-management-header or control-data indication received with job ended 
(controlled) indication on successful input operation. 


Control-data and turnaround indications received with job ended (controlled) indi- 
cation on program start request. 


Function-management-header and end-of-group indications received with job ended 
(controlled) indication on successful input operation. 


Detach indication received with job ended (controlled) indication on successful input 
operation. 


Function-management-header or control-data indication and detach indication 
received with job ended (controlled) indication on successful input operation. 


Control-data and detach indications received with job ended (controlled) indication 
on program start request. 


Control-data and turnaround indications received with job ended (controlled) indi- 
cation on program start request. In addition, the remote system requested confir- 
mation. 


Turnaround indication received with job ended (controlled) indication on successful 
input operation. In addition, the remote system requested confirmation. 


Remote system requested confirmation. The local application program continues to 
receive data. Job ended (controlled) indication received. 


Parity error or stop bit error (framing) or both received with job ended (controlled) 
indication on successful input operation. 


End-of-group indication received with job ended (controlled) indication on successful 
input operation. In addition, the remote system requested confirmation. 


Control-data indication received with job ended (controlled) indication on program 
start request. In addition, the remote system requested confirmation. 


Detach indication received with job ended (controlled) indication on successful input 
operation. In addition, the remote system requested confirmation. 


Control-data and detach indications received with job ended (controlled) indication 
on program start request. In addition, the remote system requested confirmation. 


Remote system message and turnaround or end-of-transmission indication received 
with job ended (controlled) indication on successful input operation. 


0221 


0223 


0225 


0227 


0228 


0230 


0231 


0233 


0235 


0237 


0238 


0242 


0244 


0245 


0246 


0247 


0254 


0257 


0258 


0259 


Remote system message received with job ended (controlled) indication on suc- 
cessful input operation. The session is still in receive state. 


Remote system message with end-of-group and job ended (controlled) indications 
received on successful input operation. 


Function-management-header indication received with system message and job 
ended (controlled) indication on a successful input operation. 


System message received with function-management-header, end-of-group, and job 
ended (controlled) indications on a successful input operation. 


System message and detach indication received with job ended (controlled) indi- 
cation on a successful input operation. 


Truncated system message and turnaround or end-of-transmission indication 
received with job ended (controlled) indication on successful input operation. 


Truncated system message received with job ended (controlled) indication on a suc- 
cessful input operation. The session is still in receive state. 


Truncated system message received with end-of-group and job ended (controlled) 
indications on a successful input operation. 


Truncated system message received with function-management-header and job 
ended (controlled) indications on a successful input operation. 


Truncated system message received with function-management-header, end-of- 
group, and job ended (controlled) indications on a successful input operation. 


Truncated system message and detach indication received with job ended (con- 
trolled) indication on successful input operation. 


Data-loss indication received with job ended (controlled) indication on successful 
input operation. 


Function-management-header or control-data indication and turnaround indication 
with job ended (controlled) indication received on a successful input operation. In 
addition, the remote system requested confirmation. 


Function-management-header or control-data indication with job ended (controlled) 
indication received on a successful input operation. In addition, the remote system 
requested confirmation. 


Function-management-header or control-data indication and detach indication with 
job ended (controlled) indication received on a successful input operation. In addi- 
tion, the remote system requested confirmation. 


Function-management-header and end-of-group indications with job ended (con- 
trolled) indication received on a successful input operation. In addition, the remote 
system requested confirmation. 


Rollback is required. The transaction program (TP) has entered the rollback- 
required state. 


The remote program has issued either a commit operation or a prepare-for-commit 
function. This requests the local program to respond by issuing a commit operation 
in order to perform the two-phase commit processing on all protected resources. 
Also, your job is being ended (controlled). 


The remote program has issued an allow-write function with the transaction- 
synchronization-level function followed by either a commit operation or a prepare- 
for-commit function. The synchronization level is “COMMIT. Your program will be 
in send state after issuing a commit operation, once the commit operation com- 
pletes successfully. Also, your job is being ended (controlled). 


The remote program has issued a detach function with the transaction- 
synchronization-level function followed by either a commit operation or a prepare- 
for-commit function. The synchronization level is “COMMIT. Your program will be 
deallocated after issuing a commit operation, once the commit operation completes 
successfully. Also, your job is being ended (controlled). 
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Major Code 03 


Major return code 03 indicates that the input operation completed successfully, but no data 
was received. 


Description 
The input operation issued by your program completed successfully, but no data was 
received. 
Figure B-4. Major Code 03 
Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0300 xX Xx Xx x X X 
0301 X Xx x X 
0302 x xX Xx 
0303 Xx Xx 
0305 Xx x X 
0306 x 
0308 Xx X x X X 
0309 x Xx Xx Xx x X x 
030C Xx X 
0310 x Xx X xX x X X 
0311 Xx 
0313 Xx 
0314 x x 
0315 xX Xx 
0317 Xx 
0318 Xx 
031C Xx Xx 
031D Xx 
0344 x x 
0345 X Xx 
0346 Xx 
0357 Xx 
0358 x 
0359 x 


Code Description 


0300 Ona successful input operation, a turnaround or end-of-transmission indication with 
no data, or a null record that was the beginning or middle record in a group of 
records was received. 


0301 No data received on successful input operation. A turnaround indication was not 
received. Continue to receive. 


0302 ~=—‘ Fail indication received with no data on successful input operation. 
0303 = End-of-group indication received with no data on successful input operation. 


0305 Function-management-header or control indication received with no data on suc- 
cessful input operation. 


0306 Control-data and turnaround indications received with no data on program start 
request. 
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0308 
0309 


030C 


0310 
0311 


0313 


0314 


0315 


0317 


0318 


031C 


031D 


0344 


0345 


0346 


0357 


0358 


0359 


Detach indication received with no data on successful input operation. 


Job ended (controlled) indication received on read-from-invited-program-devices 
operation. 


Function-management-header or control-data indication and detach indication 
received with no data on successful input operation. 


Timer interval has ended. 


Control-data indication and detach indication received with no data on an input 
operation. 


Control-data and turnaround indications received with no data on program start 
request. In addition, the remote system requested confirmation. 


Turnaround indication received with no data on a successful input operation. In 
addition, the remote system requested confirmation. 


Remote system requested confirmation. The local application program continues to 
receive data. 


End-of-group indication received with no data on successful input operation. In 
addition, the remote system requested confirmation. 


Control-data indication received with no data on program start request. In addition, 
the remote system requested confirmation. 


A detach indication received with no data on a successful input operation. In addi- 
tion, the remote system requested confirmation. 


Control-data and detach indications received with no data on program start request. 
In addition, the remote system requested confirmation. 


Function-management-header or control-data indication and turnaround indication 
received with no data on a successful input operation. In addition, the remote 
system requested confirmation. 


Function-management-header or control-data indication received with no data on a 
successful input operation. In addition, the remote system requested confirmation. 


Function-management-header or control-data indication and detach indication 
received with no data on a successful input operation. In addition, the remote 
system requested confirmation. 


The remote program has issued either a commit operation or a prepare-for-commit 
function. This requests the local program to respond by issuing a commit operation 
in order to perform the two-phase commit processing on all protected resources. 


The remote program has issued an allow-write function with the transaction- 
synchronization-level function. function followed by either a commit operation or a 
prepare-for-commit function. The synchronization level is “COMMIT. Your program 
will be in send state after issuing a commit operation, once the commit operation 
completes successfully. 


The remote program has issued a detach function with the transaction- 
synchronization-level function followed by either a commit operation or a prepare- 
for-commit function. The synchronization level is “COMMIT. Your program will be 
deallocated after issuing a commit operation, once the commit operation completes 
successfully. 


Major Code 04 


Major return code 04 indicates that an output exception occurred. 


Appendix B. Communications Error Handling B-11 


Description 
An output exception occurred because your program attempted to send data when it should 
be receiving data. The data from your output operation was not sent. You can attempt to 


send data later. 


Figure B-5. Major Code 04 
Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0402 X X 
0411 
0412 Xx X X X X Xx X 


Code Description 
0402 _~—s— Fail indication received. Your program must receive. 
0411 Message for your program is waiting to be received. 


0412 Data for your program is waiting to be received, or a negative response has been 
received from the remote system, and your program has not been informed. 


Major Codes 08-11 


Major return codes 08-11 indicate that miscellaneous program errors occurred. 


Description 
The operation just attempted by your program was not successful. The operation may have 


failed because it was issued at the wrong time. 


Figure B-6. Major Codes 08-11 

Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
0800 X X X X Xx X X 
1100 Xx X X Xx X X X 


Code Description 


0800 Acquire operation was not successful because your program tried to acquire a 
program device that has already been acquired. 


1100 Read-from-invited-program-devices operation was not successful. 


Major Code 34 
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Major return code 34 indicates that an input exception occurred. 


Description 
The input operation attempted by your program was not successful. The data received was 
too long for your program’s input buffer or was not compatible with the record format speci- 


fied on the input operation. 


Figure B-7 (Page 1 of 2). Major Code 34 


Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
3401 Xx Xx x X Xx 
3421 x 
3422 x 


Figure B-7 (Page 2 of 2). Major Code 34 

Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
3431 x 
3441 x Xx Xx Xx x X X 
3451 x Xx Xx Xx x X Xx 
3461 x 
3471 x 
3481 x 

Code Description 

3401 Input operation rejected because data received was too long for your program’s 
input buffer. 

3421 Control-data indication received. An input exception occurred because the program 
received data that exceeded its maximum record length. The data has been trun- 
cated. The local application program continues to receive data. 

3422 Control-data indication received with program start request. An input exception 
occurred because the program received data that exceeded its maximum record 
length. The data has been truncated. The local application program continues to 
receive data. 

3431 An input exception occurred because the program received data that exceeded its 
maximum record length. The data has been truncated. The local application 
program continues to receive data. 

3441 The record format selected by the format selection option does not match the 
record format specified on the read. 

3451 The file record size specified is not large enough for the data and indicators 
received, or it is not large enough for the indicators received. 

3461 Partial record received because remote system sent an error condition before com- 
pleting the record. 

3471 An input exception occurred because the program received data that exceeded its 
maximum record length. The data has been retained and will be returned on sub- 
sequent input operations. The local application program continues to receive data. 

3481 Control-data indication received. An input exception occurred because the program 


received data that exceeded its maximum record length. The data has not been 
truncated. The local application program may continue to receive the remaining 
data on subsequent input operations. 


Major Code 80 


Major return code 80 indicates a permanent system or file error (nonrecoverable). 


Description 

A nonrecoverable file or system error has occurred. The underlying communications support 
may have ended and your session has ended. If the underlying communications support 
ended, it must be established again before communications can resume. Recovery from this 
error is unlikely until the problem causing the error is detected and corrected. 


Figure B-8 (Page 1 of 2). Major Code 80 


Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
8081 Xx X X X Xx X X 
8082 X X X X Xx X X 
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Figure B-8 (Page 2 of 2). Major Code 80 

Asynchro- Intra- 
Code APPC nous BSCEL Finance system Retail SNUF 
80B3 X X Xx Xx x X Xx 
80C0 Xx 
80D0 X 
80EB xX xX X Xx x X Xx 
80ED xX xX Xx Xx x X X 
80EF xX xX Xx Xx x X Xx 
80F8 xX X Xx Xx x X Xx 
80F9 xX 
80FA X 
80FB X 


Code Description 

8081 System error abnormally ended the support provided by the communications type. 
8082 Communications device not usable or error recovery canceled by operator. 

80B3 _ICF file not available. 

80C0 _ Session failed. 

80D0 Remote transaction program not available. No retry allowed. 


80EB Open operation was tried but was not successful. Either an open option was speci- 
fied that was not valid, or there is a mismatch between the file and the program. 


80ED __ File level check error occurred on open operation. 
80EF User not authorized to file. 
80F8 Open operation not successful because the file is already open or it is in error. 


80F9 _==The operation attempted by your program was not successful because a system 
error condition was detected. Rollback required. 


80FA The operation attempted by your program was not successful because the device 
supporting communications between your program and the partner location is not 
usable. For example, this may have occurred because communications were 
stopped for the device by a Hold Communications Device (HLDCMNDEV) 
command. Your program should not issue any operations to the device. Rollback 
required. 


80FB An irrecoverable error has occurred on the session. The session was ended abnor- 
mally either by the partner system or because of a partner protocol error. Rollback 
required. 


Major Code 81 


Major return code 81 indicates a permanent session error (nonrecoverable). 


Description 

A nonrecoverable session error occurred during an I/O operation. Your session cannot con- 
tinue and has ended. Before communications can resume, the session must be established 

by using an acquire operation or another program start request. Recovery from this error is 

unlikely until the problem causing the error is detected and corrected. Operations directed to 
other sessions associated with the file should be expected to work. 
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Figure B-9. Major Code 81 
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Code 
8101 
810A 


8140 
8187 


8191 


8192 
8193 
8194 


Description 
Protected password could not be built. 


Combination of values detected on an input or output operation was not valid. Both 
CODE(ASCIl) and TRNSPY(*YES) were specified. 


Cancel reply was received for a previous inquiry or notify message. 


Block length or record length is greater than buffer size on an input or output opera- 
tion. 


Permanent line error occurred on an output operation, or station (controller) error 
occurred on an input or output operation. 


Permanent line error occurred on an input operation. 
Disconnect indication (for switched lines only) received on an output operation. 


Disconnect indication (for switched lines only) received on an input operation. 
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8196 
8197 
8198 
8199 


819A 


819C 


819D 


81A3 
81A4 
81AD 


81B9 


81BA 


81C2 
81C5 
81C6 


81E9 
81F0 


81F1 


81F2 


81F3 


81F4 


81F5 


Communications support has ended the session. 
Remote system abnormally ended the session on an output operation. 
Remote system abnormally ended the session on an input operation. 


Time between successive data blocks sent to, or received by, the remote system on 
output operations is larger than specified wait time. 


Time between successive data blocks received from the remote system on input 
operations is larger than specified wait time. 


On an input operation, the length of the data block sent by the remote system was 
greater than the buffer size. 


Unexpected data or an unexpected program start request was received from the 
remote system during an active session. 


SNA session ended abnormally. 
SNA protocol violation occurred. 


Attempt to establish an SNA session was not successful. The SDLC frame size 
was not large enough to contain the response unit (RU) size. 


A data record that exceeds the maximum user record length was received on an 
input operation. 


A data record that exceeds the maximum user record length was received on an 
input operation. 


Operation failed because the local APPC could not establish a session. 
The remote program or remote system abnormally ended the session (TYPE=SVC). 


The remote program or remote system abnormally ended the session 
(TYPE=TIMER). 


Data received does not match any record format in the file with the RECID keyword. 


A network interface, permanent line, or controller error occurred on an input or 
output operation, and the system operator attempted recovery in response to the 
error message. You can learn what type of error occurred by checking the system 
operator message queue (QSYSOPR). The session has ended. Data may have 
been lost. Rollback required. 


The partner system sent a Systems Network Architecture (SNA) UNBIND command 
to your system, or the session was ended locally. Rollback required. 


On an input or output operation, the partner system ended the transmission abnor- 
mally because it could not continue the session. The session has ended. Rollback 
required. 


The partner program or partner system abnormally ended the session (TYPE=SVC). 
Rollback required. 


The partner program or partner system abnormally ended the session 
(TYPE=TIMER). For example, the partner program may have been canceled by the 
operator. Rollback required. 


An input operation was issued and the format selection option for the ICF file was 
*RECID, but the data received did not match any record formats in the file. There 
was no format in the file defined without a RECID keyword, so there was no default 
record format to use. The session has ended. Rollback required. 


Major Code 82 


Major return code 82 indicates that the open or acquire operation failed. 


Description 


Your attempt to establish a session was not successful. The error may be recoverable or 
permanent, and recovery from it is unlikely until the problem causing the error is detected 
and corrected. 
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Figure B-10 (Page 2 of 2). Major Code 82 
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X X X X X X 


82F0 
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Code 
8209 


820A 


8221 


8233 
8281 
8282 
8285 
8287 
8289 


828B 


828C 


828D 


828E 


8290 


8291 


8293 


8297 


Description 


An open or acquire operation was not successful because a prestart job is to be 
ended. 


Combination of values detected was not valid. Both CODE(ASCII) and 
TRNSPY(*YES) were specified, or BLOCK(*“USER) and RMTBSCEL(*YES) were 
specified. 


SNA command received for remote location or device description that was not sup- 
ported or not valid. 


Program device name is either missing or not valid. 

System error abnormally ended the support provided by the communications type. 
Communications device not usable or error recovery canceled. 

Attempt to automatically call remote system failed. 

Block Length or record length greater than buffer size. 


Combination of values detected during an acquire operation was not valid. A record 
separator and text transparency were both specified. 


Combination of values detected during an acquire operation was not valid. The 
maximum user record length specified was greater than the block length. 


Combination of values detected during an acquire or open operation was not valid. 
GRPSEP(*DEV3740) and BLOCK(*ITB) were both specified. 


Combination of values detected during an acquire or open operation was not valid. 
TRUNC(*YES) and BLOCK(*ITB) were both specified. 


Combination of values detected during an acquire or open operation was not valid. 
TRUNC(*YES) and BLOCK(*ITB) were both specified, or TRUNC(*YES) and 
BLOCK(*NOSEP) were specified. 


Combination of values detected during an acquire or open operation was not valid. 
Blank compression and text transparency were both specified. 


Permanent line error or station (controller) error occurred on an unsuccessful open 
or acquire operation. 


Disconnect indication (for switched lines only) received from remote system during 
an acquire or open operation. 


Remote system ending line transmission. 


82A0 


82A1 


82A2 


82A4 
82A5 


82A6 
82A7 


82A8 


82A9 


82AA 


82AB 
82AC 


82AD 


82B3 


82B4 


82B5 


82BB 


82C3 
82EA 


82EC 


82EE 


82EF 


82F0 
82F2 


82F4 
82F5 
82FA 


A record separator character that was not valid was specified on the ADDICFDEVE 
or OVRICFDEVE command. 


Logon portion of the acquire operation failed. Either the host subsystem was not 
active, or a remote program name that was not valid was specified in the APPID 
parameter. 


User ID or password that was not valid was received on the INIT-SELF. 
SNA protocol violation occurred. 


Combination of parameter values detected during an acquire operation was not 
valid. *YES was specified for the MSGPTC and BATCH parameters. 


SNA bind command failed. 


The specified program device was already in use when the open or acquire opera- 
tion was attempted. 


The maximum number of program devices allowed for the ICF file was reached 
when the open or acquire operation was attempted. 


Acquire to requesting program device rejected because *REQUESTER device was 
not available, was already acquired, or a CPl-Communications requesting conversa- 
tion was already allocated. 


Operation failed because remote location or device not found, or device was found 
but not usable. 


Operation failed because device not varied on. 


Acquire operation failed because the remote location specified for the device was 
not *REQUESTER. 


Attempt to establish an SNA session was not successful. The SDLC frame size 
was not large enough to contain the RU size. 


Operation failed because device is being used by a different job or no sessions are 
currently available for specified remote location. 


Operation failed because System/36 application program cannot open an ICF file to 
a program device for SNA 3270 program interface. 


Operation not successful because SNA 3270 program interface session cannot use 
SNUF device from earlier release. 


Acquire operation failed because device specified was reserved for a program start 
request from host system. 


Mode description was not found. 


*RECID format selection processing was requested to a file that contains no record 
formats with a *RECID keyword. 


The acquire operation was not successful because CNVTYPE(*USER) is not valid 
with FMTSLT(*RMTFMT); or this communications type does not support 
FMTSLT(*RMTFMT). 


An operation was attempted to a device that is not supported for an ICF file. 


An open or acquire operation was attempted to a device the user is not authorized 
to use, or to a device in service mode. 


Error recovery not performed for file. 


Conversation type specified for the requesting program device does not match 
value received from source program. 


Open operation for input only not valid for a source program. 
*“RMTFMT format selection parameter not valid on acquire operation. 


The local LU rejected the allocation request because the local program specified a 
synchronization level (on the evoke function) that the remote LU does not support. 
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82FB _‘— Protected conversations are not supported on single session devices. 


82FC ‘Protected conversations are not supported by the System/36 and System/38 envi- 
ronments. 


82FD The exchange log name process failed. 


82FE The evoke function issued by your program was not successful because a 
resource could not be placed under commitment control. 


Major Code 83 


Major return code 83 indicates that a session error occurred (the error is recoverable). 


Description 
An error occurred during an I/O operation, but the session is still active. Recovery within 
your program might be possible. 


Figure B-11 (Page 1 of 2). Major Code 83 
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Figure B-11 (Page 2 of 2). Major Code 83 
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Code 
830B 


830C 


830D 
8311 


8316 
8319 


831A 
831B 


831C 


< |< | K | xX | KL KX | xX 


Description 


An input or output operation was attempted to a program device that was not 
acquired. 


Length of function-management-header received from host system is greater than 
the maximum RU length. 


Shutdown indication received from host system. 


Output operation was attempted while a message containing sense data was 
waiting to be received. 


Evoke failed because target program was not found. 


Negative response with sense data was issued to your program’s previous or 
current output request by the other program. 


Evoke failed to complete successfully, or the target program ended abnormally. 


Sense data that was not valid was specified on a negative-response function issued 
by your program. 


Operation is not valid at this time. An indication was received that the return code 
from a previous operation was not properly handled by your program. 
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831E 
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Operation or combination of operations not valid, or operation not supported by the 
communications type. 


Length of data record or data specified on the operation not valid. 


Request-to-write, negative-response, or detach function not valid while your 
program is in send state. 


Cancel issued while in receive state, or fail indication received while in send state. 


Function-management-header indication issued by your program at wrong time. 
Function-management-header is valid only with the first record in the chain. 


Cancel or negative-response indication issued as a single record. These functions 
are only valid within a group of records. 


Input or output operation that was not valid was issued when no transaction existed. 
Your program may have expected more data when there was none. 


Evoke not valid in this session. Your program was started by a remote program 
start request. 


Both programs were attempting to receive. 


Output operation with zero record length detected when GRPSEP(*OFCSYS) was 
specified. 


Release operation not valid after an invite function. 
Attempted function is not valid following an invite function. 


Evoke function or release operation that was not valid was issued before a trans- 
action completed. 


Cancel indication or cancel and turnaround indications received on an input opera- 
tion. 


Cancel indication received without turnaround indication on an input operation. 
Cancel and detach indications received on an input operation. 


Program name missing on an evoke sent by your program, or the length of the 
program name was not valid. 


The remote program has quiesced the SNA session on which this transaction is 
running. 


Value received in SNA header that was not valid. 
The host system has sent a clear request to reset the session. 


Fail indication (TYPE=PROG) received with no data on an input operation. No data 
truncated. 


Fail indication (TYPE=SVC) received with no data on an input operation. No data 
truncated. 


Fail indication (TYPE=PROG) received on an input or output operation with or 
without a confirm indication. Data may have been lost. 


Fail indication (TYPE=SVC) received on an input or output operation with or without 
a confirm indication. Data may have been lost. 


Fail indication (TYPE=PROG) received on an input operation. The last logical 
record truncated. 


Fail indication (TYPE=SVC) received on an input operation. The last logical record 
truncated. 


Confirm indication not allowed when SYNLVL(*NONE) is specified on the evoke 
function. 


Security information specified on the evoke function not valid. Request rejected by 
remote system. 


83CF Remote location or remote program does not support the specified conversation 
type. Request rejected by remote system. 


83D0 Program name specified on the evoke function is not currently available. Retry is 
allowed. 


83D1 Program initialization parameters not allowed. Request rejected by remote system. 


83D2 Program initialization parameters not specified correctly. Request rejected by 
remote system. 


83D3 = Synchronization level specified on the evoke function not supported by remote 
program. 


83D5 Response-to-confirm request required. 
83D6 Response-to-confirm request not valid in current state. 
83E0 Record format not defined for the file. 


83E8 Cancel-invite function not valid because an invite function was not previously 
issued. 


83F1 The file was closed while the transaction was still active. 

83F3 Length specification on a basic conversation not valid. 

83F6 User-defined data not valid on an unsuccessful output operation. 

83F7 Length of user-blocked data record not valid on an unsuccessful output operation. 
83F8 Operation attempted to a device marked in error. 

83F9 Your program issued an operation that did not complete the data record. 


83FB Your program closed the ICF file while the transaction was still active. The system 
abnormally ended the transaction with the partner program. Rollback required. 


83FC Your program attempted to issue an operation to a program device that is marked 
in error due to a previous I/O or acquire operation. Your program may have 
handled the error incorrectly. Rollback required. 


83FD All protected resources have rolled back in the part of the distributed transaction 
affected by the function. 


83FE The state of one or more protected resources is not known. The changes probably 
are or will be rolled back, but changes to some resources may be committed 
instead. Your protected LUW is in the rollback required state. 


83FF The state of the protected resources is not consistent. One or more resources have 
advanced to a new synchronization point (have been committed instead of rolled 
back). Your protected LUW is in the rollback required state. 


This return code occurs only when processing has been abnormally interrupted 
through operator intervention. 


Failed Program Start Requests 


Message CPF1269 is sent to the system operator message queue when the local system 
rejects an incoming program start request. You can use the message information to deter- 
mine why the program start request was rejected. 


The CPF1269 message contains two reason codes. One of the reason codes can be zero, 
which can be ignored. If only one nonzero reason code is received, that reason code repre- 
sents the reason the program start request was rejected. If the System/36 environment is 
installed on your AS/400 system, there can be two nonzero reason codes. These two 
reason codes occur when the OS/400 system cannot determine whether the program start 
request was to start a job in System/36 environment or in the OS/400 environment. One 
reason code explains why the program start request was rejected in the System/36 environ- 
ment and the other explains why the program start request was rejected in the OS/400 envi- 
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ronment. Whenever you receive two reason codes, you should determine which 
environment the job was to run in and correct the problem for that environment. 
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Appendix C. Open Feedback and I/O Feedback 


This appendix contains information concerning the open 
feedback and I/O feedback areas. 


If you are using the ILE COBOL, or ILE RPG support, you 
need to add the offset values shown in Figure C-1 to the 
offset values listed in this appendix to access information 
from the feedback areas. 


For the ILE C programming language, the Open Feedback 
Area is accessed with a call to the _Ropnfbk function. The 
Common I/O Feedback Area is accessed with a call to the 
_Riofok function. The File Dependent Feedback Area is 
accessed by adding an offset in the Common I/O Feedback 


Area to a pointer to the Common I/O Feedback Area. See 
the ILE C/400 Programmer’s Guide for more information. 


Open Feedback Area 


You can use the open feedback area information, set during 
open processing, as long as the file is open. The support 
provided by the high-level language you are using deter- 
mines how to access this information. See the appropriate 
language reference book for more information. 


The complete open feedback area is described in the Data 
Management book. Figure C-2 shows the fields relevant to 
ICF support. 


Figure C-1. Offset Values for ILE COBOL, and ILE RPG 


Open 
Feed- Common 
back /O Feed- 
Language Area back Area File Dependent Feedback Area 
ILE COBOL 01 0 144 
FORTRAN/400_ 01 0 1442 
ILE RPG 81 241 367 


1 Separate structure from the Common I/O Feedback Area. 


2 Use offset in the first 2 bytes of the Common I/0 Feedback Area to get to the File Dependent Feedback Area. 


Figure C-2. Open Feedback Area 


Length 
Offset Data Type in Bytes Contents 
0 Char- 2 Type of file being opened (DS = device file). 
acter 
2 Char- 10 Name of the file being opened. 
acter 
12 Char- 10 Name of the library containing the file. 
acter 
44 Binary Record length. 
66 Binary File type (11 = ICF). 
116 Char- 10 Program device name of the requester. This field contains the program device name, if valid for this job 
acter and file. If it is not valid, this field contains *N. 
133 Char- 2 Open identifier. This value is unique for a full open of a file (SHARE (* NO)) or the first open of a file 
acter with (SHARE (* YES)). It allows the user to match this file to an entry on the associated data queue. 
135 Binary 2 Maximum record length. This value includes the data, source sequence numbers, option indicators, 
response indicators, and P-data, if applicable. If this field is 0, then use the field from offset 44. 
146 Binary 2 Number of program devices added to the file using the Add Intersystem Communications Function Device 
Entry (ADDICFDEVE) command, or number of program devices defined to the file using the Override ICF 
Device Entry (OVRICFDEVE) command and acquired by the program. 
148 Char- Vari- Program device name definition list. Refer to Figure C-3. 
acter able 
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Program Device Definition List 


Figure C-3 on page C-2 shows the mapping for a single 
entry of the program device definition list, which is physically 
a part of the open feedback area. However, the fields in the 
definition list are not necessarily set when the file opens. 


Figure C-3. Program Device Definition List 


Offset 
0 

60 

70 

71 


76 


78 


79 


Length in 
Data Type Bytes 


Character 10 
Character 10 
Character 1 
Character 1 


Character 2 


Character 1 


Character 1 


Contents 


Program device name. 


Device description name. 


Device class. Hex 0B for ICF. 


Communications type: 


0A 
0E 
1E 
1F 
20 
42 
43 


BSCEL device 
APPC device 
Intrasystem device 
Asynchronous device 
SNUF device 
Finance device 
Retail device 


Status flags, as follows: 


Bit 3, acquire status: 


0 Program device not acquired. 
1 Program device acquired. 


Bit 4, invite status: 


0 Program device not invited. 
1 Program device invited. 


Bit 5, data-available status: 


0 Data not available. 
1 Data available. 


Bit 6, transaction status: 


0 Transaction not started. An evoke has not been sent, a detach has been sent or received, or 


the transaction has completed. 


1 Transaction started. The session is active, an evoke has been sent or received, and the 


transaction has not ended. 
Bit 7, session type: 


0 Session created with source program 


1 Requesting program device 


Synchronization level: 


Hex 00 


Hex 01 


Hex 02 


allowed. 


allowed. 


Conversation type: 


Hex DO Basic 
Hex D1 Mapped 
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The transaction was started with SYNLVL(*NONE). Confirm processing is not 
The transaction was started with SYNLVL(*CONFIRM). Confirm processing is 


The transaction was started with SYNLVL(*COMMIT). Confirm processing and two- 
phase commit processing are allowed. 


Input/Output Feedback Area 


The results of I/O operations are communicated to the 


program using ICF messages and I/O feedback information. 


The support provided by the high-level language you are 
using determines how to access this information. See the 
appropriate communications language reference book for 


The feedback area consists of two parts: 


« Acommon I/O feedback area 
¢ A file-dependent I/O feedback area 


Common I/O Feedback Area 


more information. 


The complete common I/O feedback area is described in the 
Data Management book. Figure C-4 shows the fields rele- 
vant to ICF. 


Figure C-4. Common I/O Feedback Area 


Length in 
Offset Data Type Bytes Contents 
0 Binary 2 Offset to device-dependent feedback area. Refer to Figure C-5. 
2 Binary 4 Output operation count. Updated only when a output operation completes successfully. This field is not 
updated for fail, request-to-write, cancel, or negative-response functions, or if the record length is 0. 
6 Binary 4 Input operation count. Updated only when an input operation completes successfully and data is 
received. 
10 Binary 4 Output then input operation count. Updated only when a combined output then input operation com- 
pletes successfully. 
14 Binary 4 Count of other operations. Number of successful acquire and release operations. 
18 Char- 1 Reserved. 
acter 
19 Char- 1 Current operation (the last requested): 
erier Hex 01 Input 
Hex 05 Output 
Hex 06 Output then Input 
Hex 11 Release 
Hex 12 Acquire 
20 Char- 10 Name of the just-processed record format, which is either specified on the I/O request or determined by 
acter default processing. 
30 Char- 2 Communications class and type: 
acter Hex OBOA BSCEL 
Hex OBOE APPG 
Hex OB1E Intrasystem 
Hex OB1F Asynchronous 
Hex 0B20 SNUF 
Hex 0B42 Finance 
Hex 0B43 Retail 
32 Char- 10 Program device name (for operation just completed). 
acter 
42 Binary 4 Record length specified by the record format processed by the last I/O operation, not including any indi- 
cators or program-to- system fields (P-data fields). For Evoke operations, this field specifies the length 
of any user-defined parameters. 
46 Reserved 82 Not applicable to ICF communications. 
128 Binary 2 Length of the record associated with the last I/O operation. This value includes data, option indicators, 
response indicators, and P-data, if applicable. 
130 Reserved 14 Not applicable to ICF communications. 


File-Dependent I/O Feedback Area 


Figure C-5 shows the communications type-dependent fields 


relevant to ICF. 
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Figure C-5. File-dependent I/O Feedback Area 


Length 
in ICF 
Offset Data Type Bytes Contents Type 
5 Binary 4 Actual record length. This field is set as follows: All 
Input: Contains the actual length of user data received from the remote system or 
device. When all the data cannot be contained in the record format used, the length of 
data is provided, if known. If the actual length cannot be determined (for example, if 
DTACPR(*YES) is specified for BSCEL), this field is set to hex FFFFFFFF. When a 
partial record is received, the length of the data received is provided. If the input opera- 
tion completes with an error (other than partial record or buffer too small), the contents 
of the field are undetermined. 
Output: Contains the number of bytes moved from your program to the output buffer. If 
the output operation completes with an error, the contents of the field are undetermined. 
34 Char- 2 Major return code. All 
acter 
36 Char- 2 Minor return code. All 
acter 
38 Char- 8 Negative-response error data. For some return codes, this field can contain more detailed APPC 
acter information about the reason for the error. Finance 
Retail 
46 Char- 1 Safe indicator: BSCEL 
Alor 0 Off. 
1 On indicates that a block ending with ETX was received. The Safe indicator is not set for 
BLOCK(*USER). 
47 Char- 1 Reserved. 
acter 
48 Char- 1 Request-to-write indication was received. APPC 
ace 0 Request-to-write not received. eit 
1 Request-to-write was received. 
Intrasystem 
49 Char- 10 Remote format name received from the remote program on an input operation. APPC 
acter Intrasystem 
63 Char- 8 Mode associated with the program device. APPC 
acter 
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Appendix D. EBCDIC and ASCII Character Sets 


The following charts show the EBCDIC and ASCII character sets. The charts are provided 
to show the data link control characters that are used in data communications. 


EBCDIC Character Set 


Figure D-1 shows a complete EBCDIC character set. 


Main Storage Bit Positions 0,1,2,3 
Main Storage [0000/0001 0010/0011|0100 0101/0110 |0111/1000 |1001 1010/1011 1100 |1101 1110/1111 
Bit Positions 
4,5,6,7 Hex;/ 0 | 1/2 ]3 /4/5 |6/7]8{/}9/)A]Bi/}c|]DIE|F 
0000 0 |NUL| DLE DS sP | & | - { } \ | 0 
0001 1 |SOH|DC1 SOS RSP / a lj |w A | J | NSP| 1 
0010 2 |STX|DC2/FS | SYN b | k | s Be.) cso 
0011 3 | ETX | DC3 WUS/IR c | | t PN) ee? le el 28 
ENP~ | INP 
0100 45 SEL Fe. 70 /'PB d | miu D|mM|]u|4 
0101 5 |HT |NL |LF |RS e |n|v E|/n|]vJs5 
0110 6 BS ETB | NBS f o | Ww F|/O} WwW) 6 
0111 7 |DEL| POC|ESC | EOT g9 |p| x G/p|x|7 
1000 8 |GE | CAN SBS h | q y se © a 
1001 9 |SPS|EM IT r z | |R | z]9 
1010 A |RPT|UBS|SM “| REF] |} Veh 4 SHY 
Sw | 
1011 B |vT |CcU1/FMT|cu3} . Sane # 
° [| 
1100 c |FF |IFS < |. | %le al : 
1101 D |CR |IGS ENQ/NAK| ( ? 
DC4| — 
1110 E |soO |IRS ACK ron eS |e U! 
1111 F jst | jBEL|suB} | |] ? | EQ 


RSLS196-0 


Figure D-1. EBCDIC Character Set 
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ASCII Character Set 
Figure D-2 shows the ASCII character set. 


Main Storage Bit Positions 0,1,2,3 

Main Storage 0000/0001 (0010/0011 /0100 [0101 |0110 0111 [1000 1001 [1010 |1011 1100 |1101 1110 111% 
Bit Positions 
45,67 |;Hex, 0 | 1/2 /3 |]4 /5 |6/7 })]8 |9 |A!]B)C}]D|E|F 

0000 0 |NUL|DLE | SP | 0 @ P % p 

0001 1 |SOH/DC1 | 1 A Q a q 

0010 2 |STX|pc2) " 2 B R b r 

0011 3 | ETX|DC3) # 3 Cc S) c Ss 

0100 4 |EOT/pCc4| $ 4 D T d t 

0101 5 | ENQ|NAK| % | 5 E U e U 

0110 6 | ACK|SYN] & 6 F Vv f Vv 

0111 7 |BEL/ETB ' 7 G W g Ww 

1000 8 |BS |cAN| ( | 8 | H | X | h |} x 

1001 9 |HT JEM | ) 9 | Y y 

1010 A |LF |SUB| °* : J Z j z 

1011 B |VT |ESC + : K [ k { 

1100 GPP Tet ye | se Ee IS | 

1101 D |CR |G@s - = M ] m } 

1110 E |SO |RS 2 > N ~ n Ww 

1111 F |Sl US / 4 O _ 0 | DEL 


RSLS197-1 


Figure D-2. ASCII Character Set 
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Appendix E. File Transfer Support 


This appendix describes the application interface to the 
AS/400 system file transfer support (FTS). FTS is a func- 
tion of the operating system that moves the file members 
from one system to another using asynchronous, advanced 
program-to-program communications (APPC), or binary syn- 
chronous communications equivalence link (BSCEL) commu- 
nications support. 


File Transfer Support Overview 


Using FTS, a user application program can send or retrieve 
database file members between one AS/400 system and 
another AS/400 system, send database file members to 
System/36, and retrieve files and library members from 
System/36. System/36 Release 5.1 with preventive 
PTF—DK3700 is required to communicate with System/36. 
FTS does not support the sending and retrieving of database 
file members between an AS/400 system and a System/38. 


If an AS/400 database file has more than one member, you 
can send or retrieve only one member at a time. 


If a database file does not exist, it is created and the 
member is added. 


Note: The database file is created with *NOMAX as the 
maximum member (MAXMBR) value. If a database file 
exists and the member does not exist, the member is added. 
If a member exists, you can specify that the member be 
replaced. 


FTS running on the local system communicates with FTS on 
the remote system to complete the request. FTS defines the 
target system as the system that receives the object, which 
can be the local system or the remote system. For example, 
if system A in Figure E-1 sends a database file member to 
system B using FTS, system B is the target system. If 
system A retrieves a database file member from system B 
using FTS support, system A is the target system. 


System A System B 

FTS Send > File > File 

FTS Retrieve > File 
ae ee File 
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Figure E-1. Example of File Transfer Support 


An application program can use FTS by calling the program 
QY2FTML. 


© Copyright IBM Corp. 1997 


Note: FTS uses the file QSYS/QY2ICFF. Do not change or 
delete this file. This file contains the DDS formats for the 
ICF file. 


Either a high-level language program or a control language 
(CL) program can call FTS. FTS is supported by all high- 
level languages. Refer to the ILE C, COBOL/400, RPG/400, 
and CL program examples in this appendix for more details. 


FTS evokes a partner application on the remote system. 
You do not need to have a user application on the remote 
system to use FTS. 


FTS assumes that the user ID used on the remote system is 
the same as the user ID for the job from which FTS was 
started. If you are creating a file on an AS/400 system, the 
sending user ID becomes the owner. 


Data Compression 


The System/36 requires FTS data to be compressed. Except 
for token-ring lines, the AS/400 system does not compress 
data when the line speed (LINESPEED parameter on the line 
description) is set greater than or equal to 56000 bits per 
second (bps). Regardless of line speed or type, the optional 
COMPRESS parameter can be used to specify whether data 
compression is done. 


For token-ring networks, FTS always compresses data. 


File Transfer Considerations 


The following sections describe in more detail the objects 
that you can send and retrieve using FTS. 


To and From an AS/400 System 


You can send physical file members to or retrieve them from 
an AS/400 system. 
You cannot send or retrieve the following objects: 


e Physical files that are part of an interactive data defi- 
nition utility (IDDU) dictionary 


e Physical files being sent to a receiving AS/400 system, 
where the receiving AS/400 system has logical files built 
over the physical files 


Note: The logical files must be deleted by the user, 
then the FTS can successfully transfer the physical files. 


¢ AS/400 program objects 
e Logical files 


e Device files 


AS/400 System Retrieving from System/36 


On an AS/400 system, you can retrieve the following objects 
from System/36: 


e System/36 files 
¢ System/36 library members 


You cannot retrieve the following objects: 


¢ System/36 data dictionary 
¢ System/36 folder/document 


When you retrieve a file from System/36, the file is stored on 
the AS/400 system as a physical file within a library. If you 
do not specify a member name, the member name becomes 
the creation date with an M added as the first character. 


When you retrieve a library member from System/36, the file 
is stored on the AS/400 system as a physical file member in 
a file within a library. If you do not specify the file name, the 
type of member determines the file name. Source library 
members are stored in file QS36SRC, procedure library 
members are stored in file QS36PRC, subroutine library 
members are stored in file QS36SBR, and load library 
members are stored in file QS36LOD. 


Note: A System/36 index file cannot be added as a member 
to a keyed file created on an AS/400 system. 


AS/400 System Sending to System/36 


You can send physical file members from an AS/400 system 
to System/36. 


You cannot send the following objects: 


e Physical files that are part of an interactive data defi- 
nition utility (IDDU) dictionary 


e¢ AS/400 program objects 

¢ Logical files 

¢ Device files 

e Keyed files with multiple key fields 


The attributes of the physical file determine if physical file 
members are stored as library members or files on 
System/36. 


If the physical file member has the attributes of a System/36 

file, it is stored as a file on System/36. The file keeps its file 
organization (such as direct, sequential, or indexed). The file 
name and date field from the parameters are used to create 

the file on System/36. 


If the physical file member being sent does not have the attri- 
butes of a System/36 file, the member is stored on 
System/36 as a library member. The library name, the 
member name, and the type field from the input parameters 
are used to create the library member on System/36. 
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Notes: 


1. If a library name, file name, or member name is greater 
than 8 characters, System/36 uses the first 8 characters 
as the name. 


2. The AS/400 system receives and keeps source 
members with no records but the System/36 does not. If 
an empty source member is sent to a System/36, the 
source member is not kept. 


Multiple Communication-Type Support 


When using FTS, your system can set up communications 
with the following communication types and specific links: 


e Advanced program-to-program communications (APPC) 
— Multiple sessions at the same time 
— Switched or nonswitched connections 
— Synchronous data link control (SDLC) links 
— X.25 links 
— Integrated services digital network (ISDN) 
— Token-ring and Ethernet local area networks 
— Advanced Peer-to-Peer Networking (APPN) capa- 
bility 
— Logical unit (LU) own 
Notes: 


1. If the optional MODE parameter is not specified, 
FTS requires use of the BLANK mode description. 
If you are using APPN support to automatically 
create APPC device descriptions, use the Display 
Network Attributes (DSPNETA) command to ensure 
that the default mode description is set to BLANK. 


2. If the optional RMTNETID parameter is not specified 
and in an APPN network, FTS cannot send files to a 
system with a different network identifier than the 
local system. The remote network identifier speci- 
fied for APPC controller and device descriptions 
used by FTS must be the same as the local network 
identifier (LCLNETID parameter) specified in the 
network attributes. 


3. FTS also runs on APPC over TCP/IP using the links 
that TCP/IP supports. 


e Binary synchronous communications equivalence link 
(BSCEL) 
— Single session only 
— Switched or nonswitched connections 


With BSCEL, you can configure the maximum user 
record length that you are going to send. This length 
cannot be greater than 4075. You must specify *YES 
for the TRNSPY parameter and *YES for the 
RMTBSCEL parameter when you configure BSCEL. 
BSCEL supports a maximum length of 8 characters for 
the user ID and a maximum of 4 characters for the pass- 
word. You must also specify “NONE for the BLOCK 
parameter (this is the default value). 


e Asynchronous communications 


— Single session only 
— Switched or nonswitched connections 


Asynchronous communications performs a logical 
link protocol to ensure data integrity. Data is sent 
as 8-bit EBCDIC, not as ASCII. When you are 
using FTS on an asynchronous line description, 
your modem must be set to full duplex. 


If your system is connected to a network by a 
packet assembler/disassembler (PAD) and you use 
FTS on an X.25 packet-switched data network 
(PSDN), you must set the X.3 parameters and any 
network-specific parameters to allow data transpar- 
ency. To achieve data transparency, set the X.3 
parameters and any network-specific parameters to 
allow the following: 


- No PAD recall using a character 

- No echo 

- No selection of data forwarding characters 
- No use of XON/XOFF 


- PAD must send interrupt when a break signal 
from start-stop mode data terminal equipment 
(DTE) is received 


- PAD must allow EBCDIC data 
- PAD must allow 8-bit transparency 


- Only forward on full packets or idle timer 


Notes: 


1. The network PAD must not perform any operations on 
the file transfer data stream. 


2. If you use FTS with AS/400 integrated PAD, the X.3 
parameter settings are ignored in order to achieve data 
transparency. 


See the Asynchronous Communications Programming book 
for more information about the X.3 parameters. 


You must create configurations for each communication type 
and vary on the configuration on both the local and remote 
systems. For further information on communications config- 
urations, see the Communications Configuration book. FTS 
establishes a link to the varied on configuration based on the 
remote location name supplied in the input parameters. 


FTS has a maximum record length of 4075. If you use 
BSCEL and configure your maximum user record length, the 
record must be at least 512 bytes long. You can, however, 
send files with less than 512-byte records. 


File Transfer Parameters 


This section describes the parameters passed to the file 
transfer program QY2FTML. FTS parameters are all posi- 
tional. You must, therefore, reserve space in your program 
for all parameters. If you do not use a parameter, fill its 
space with blanks. 


Refer to the CL Reference book for general rules about 
naming libraries, database files, and database file members. 
Refer to the System/36 System Reference book for 
System/36 naming conventions. 


To and From an AS/400 System 


Figure E-2 describes the required parameters for sending 
and retrieving files between one AS/400 system and another 
AS/400 system. 


Figure E-2 (Page 1 of 3). Transferring Files to and from an AS/400 System—Required Parameters 


Parameter Value Description 


OPTION Character File transfer option to perform. 
Length: 1 character 

Type: Input, required 

Valid values are as follows: 


¢ S—Send 
¢ R—Retrieve 
FROMLIB Library 
name Length: 10 characters 
Type: Input, required 
Valid values: Library name 
FROMFILE File name 
Length: 10 characters 


Type: Input, required 


Valid values: Database file name 


Name of the library that contains the database file. 


Name of the database file that contains the member. 
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Figure E-2 (Page 2 of 3). Transferring Files to and from an AS/400 System—Required Parameters 


Parameter Value Description 
FROMMBR Member Name of the member. 
name 


Length: 10 characters 
Type: Input, required 
Valid values: Member name 
TYPE Blanks Not needed for an AS/400 system to an AS/400 system. 
Length: 6 characters 
Type: Not applicable 
Valid values: Blanks 
TOLIB Target Name of the receiving library. 
library name Length: 10 characters 
Type: Input, not required 
Valid values: Library name 
Default: FROMLIB 
TOFILE Target file Name of the receiving database file. 
pane Length: 10 characters 
Type: Input, not required 
Valid values: File name 
Default: FROMFILE 


TOMBR Target file Name of the receiving member. 
member Length: 10 characters 
name 
Type: Input, not required 
Valid values: Member name 
Default! FROMMBR 
When you use TOMBR, consider the following: 
e If you are replacing a database member (REPLACE=Y), this is the name of the member to replace at 
the target system. 
e lf you are adding a new database member, this is the name to assign. 
TODATE Blanks Not needed for an AS/400 system to an AS/400 system. 
Length: 6 characters 
Type: Not applicable 
Valid values: Blanks 
REPLACE Character This field tells whether you want to replace the member on the target system. 
Length: 1 character 
Type: Input, not required 
Valid values: 
e Y—Replace an existing member on the target system. 
¢ N—Do not replace an existing member. 
Default: N 
If you specify REPLACE=Y for a member, you cannot use the database file containing that member for 
any other operation during the replace operation. 
RMTLOCNAME _ Location Name of the remote location with which you are communicating. 
Name 


Length: 8 characters 
Type: Input, required 


Valid values: Remote location name in a varied-on device description. 
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Figure E-2 (Page 3 of 3). Transferring Files to and from an AS/400 System—Required Parameters 


Parameter Value 


Description 


PASSWORD PASSWORD 


RTNCODE Character 


MESSAGE-ID Character 


Password for signing on the remote system. 

Length: 10 characters 

Type: Input. This field is required only if the remote system has password security active. 
Valid values: Password 


This field contains the return code. FTS returns this value to the application program to indicate the result 
of the transfer. 


Length: 1 character 
Type: Output 
Valid values: 


¢ OQ —Normal completion. 
¢ 1—An error was detected at the local system. 
e¢ 2—An error was detected at the remote system. 


For return codes 1 and 2, the specific error is sent to the job log of both systems, and the message-id is 
returned to the user in the message-id field. (See “File Transfer Support Messages” on page E-34 for 
more information.) 


This field contains the message-id for the specific error if the value returned in the RTNCODE field is 1 or 
2 (indicating an error). 


Length: 8 characters 
Type: Output 


Valid values: Any message-id listed in the message section (See “File Transfer Support Messages” on 
page E-34 for more information.) 


Figure E-3 describes the optional parameters for sending 
and retrieving files between one AS/400 system and another 


AS/400 system. 


Figure E-3 (Page 1 of 2). Transferring Files to and from an AS/400 System—Optional Parameters 


Parameter Value Description 
RMTNETID Remote This field contains the network ID of the network where the remote location resides. 
network Length: 8 characters 
identifier 
Type: Input, not required 
Valid values are as follows: 
¢ Remote network ID 
¢ *LOC 
¢ *NETATR 
e *NONE 
Default: *LOC 
MODE Mode name This field contains the mode name used. 


Length: 8 characters 
Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *NETATR 


Default: *NETATR 
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Figure E-3 (Page 2 of 2). Transferring Files to and from an AS/400 System—Optional Parameters 


Parameter Value Description 
LCLLOCNAME Local This field contains the local location name. 
location Length: 8 characters 
name 
Type: Input, not required 
Valid values are as follows: 
¢ Mode name 
¢ *LOC 
¢ *NETATR 
Default: *LOC 
COMPRESS Com- Indicates if data compression will be done. 
pression Length: 1 character 
indicator 
Type: Input, not required 
Valid values are as follows: 
¢ Y—Compress data 
e¢ N—Do not compress data 
¢ L—Data compression is determined by the speed specified on the line description. “Data 
Compression” on page E-1 has more information about data compression. 
Default: L 
WAITFILE Maximum This field contains the number of seconds that the program waits for the Intersystem Communications 
file wait time Function (ICF) file resources to be allocated when the file is opened. 


Length: 6 characters 
Type: Input, not required 


Valid values are as follows: 
— 000001 through 032767 seconds in character format (leading zeros are required) 
— *IMMED 
- *CLS 


Default: 000030 


AS/400 System Sending to System/36 


Figure E-4 describes the required parameters for sending 
from an AS/400 system to System/36. 


Note: The TYPE parameter determines how data is stored 
on the System/36, therefore, it is important to specify the 
value of the TYPE parameter correctly. If this parameter is 
not specified correctly, results may occur that cannot be pre- 
dicted. 


Figure E-4 (Page 1 of 3). AS/400 System Sending to System/36—Required Parameters 


Parameter Value Description 


OPTION Character File transfer option to perform. 
Length: 1 character 
Type: Input, required 
Valid values are as follows: 


° ee Refer to “AS/400 System Retrieving a File from System/36” on page E-9. This section 
describes only send. 
FROMLIB Library Name of the library that contains the database file. 
hale, Length: 10 characters 
Type: Input, required 


Valid values: Valid library name 
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Figure E-4 (Page 2 of 3). AS/400 System Sending to System/36—Required Parameters 


Parameter 


Value 


Description 


FROMFILE 


FROMMBR 


TYPE 


TOLIB 


TOFILE 


TOMBR 


TODATE 


File name 


File 
member 
name 


File 
member 
type 


Target 
library 
name 


Target file 
name 


Target 
member 
name 


Numeric 


Name of the database file that contains the member. 
Length: 10 characters 

Type: Input, required 

Valid values: Valid database file name 

Name of the member. 

Length: 10 characters 

Type: Input, required 

Valid values: Valid member name 

This field tells System/36 how to store this member. 
Length: 6 characters 

Type: Input, required 

Valid values: SOURCE, LOAD, PROC (procedure), SUBR (subroutine), valid system date, or blanks. 


SOURCE, LOAD, PROC, or SUBR must be used if the member is to be stored as a library member. A 
date or blanks can be used if the member is to be stored as a file. 


Name of the receiving library to which the member is sent. If the member’s attributes indicate that this is 
a System/36 file, this parameter must be left blank and the TOFILE parameter must be specified. 


Length: 10 characters (see note at the end of this figure) 

Type: Input, not required 

Valid values: System/36 library name, System/36 file name, and blanks 
Default: FROMLIB 


Name of the file. If the attributes of the member being sent indicate that this is a System/36 file, this 
parameter is used as the file name on System/36. 


Length: 10 characters (see note at the end of this figure) 
Type: Input, not required 

Valid values: System/36 file name and blanks 

Default: FROMFILE 


Name of the library member. If the attributes of the member being sent indicate that this is a System/36 
file, this parameter is not used. 


Length: 10 characters (see note at the end of this figure) 
Type: Input, not required 

Valid values: System/36 library member name 

Default: FROMMBR 

When using TOMBR, consider the following: 


¢ If you are replacing a library member (REPLACE=Y), this is the name of the library member to 
replace at the target system. 


e If you are adding a new library member, this is the name to assign. 


This field is used to change the date of a file sent to a System/36. Make sure that the system date 
format on the target system is the same as the format on your system. This field is not used if the 
member being sent will be used as a library member. 


Length: 6 characters 
Type: Input, not required 
Valid values: Numeric date 
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Figure E-4 (Page 3 of 3). AS/400 System Sending to System/36—Required Parameters 


Parameter Value Description 
REPLACE Character This field tells whether you want to replace the file or library member on the target system. 
Length: 1 character 
Type: Input, not required 
Valid values: 
e Y—Replace an existing file or library member on the target system. 
¢ N—Do not replace an existing file or library member. 
Default: N 
If you specify REPLACES=Y for a library member, you cannot use the library containing that member for 
any other operation during the replace operation. If you specify REPLACE=Y for a file, the file cannot be 
used for any other operation during the replace operation. 
RMTLOCNAME Location Name of the remote location with which you are communicating. 
Name Length: 8 characters 
Type: Input, required 
Valid values: Remote location name in a varied-on device description. 
PASSWORD Password Password for signing on the remote system. 
Length: 10 characters. The largest password System/36 accepts is 4 characters. 
Type: Input. This field is required only if the remote system has password security active. 
Valid values: Password 
RTNCODE Character This field contains the return code. FTS returns this value to the application program to indicate the 
result of the transfer. 
Length: 1 character 
Type: Output 
Valid values: 
¢ OQ Normal completion. 
¢ 1—An error was detected at the local system. 
e¢ 2—Ahn error was detected at the remote system. 
For return codes 1 and 2, the specific error is logged to the history file of the System/36 and to the job 
log file of the AS/400 system. The message-id is returned to the user in the message-id field. (See “File 
Transfer Support Messages” on page E-34 for more information.) 
MESSAGE-ID Character This field contains the message-id for the specific error if the value returned in the RTNCODE field is 1 or 


2 (indicating an error). 
Length: 8 characters 
Type: Output 


Valid values: Any message-id listed in the message section. (See “File Transfer Support Messages” on 
page E-34 for more information.) 


Note: Ifa library name, file name, or member name is greater than 8 characters, System/36 uses the first 8 characters as the name. 


Figure E-5 describes the optional parameters for sending 
from an AS/400 system to System/36. 
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Figure E-5. Transferring Files to and from an AS/400 System—Optional Parameters 


Parameter Value Description 


RMTNETID Remote This field contains the network ID of the network where the remote location resides. 
network 


: ra Length: 8 characters 
identifier 


Type: Input, not required 
Valid values are as follows: 


¢ Remote network ID 
¢ *LOC 

¢ *NETATR 

e *NONE 


Default: *LOC 
MODE Mode name This field contains the mode name used. 
Length: 8 characters 
Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *NETATR 


Default: *NETATR 


LCLLOCNAME Local This field contains the local location name. 
location 


Length: 8 characters 
name 


Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *LOC 
¢ *NETATR 


Default: *LOC 


COMPRESS Com- Indicates if data compression will be done. 
pression 


eae Length: 1 character 
indicator 


Type: Input, not required 
Valid values are as follows: 


¢ Y—Compress data 

¢ N—Do not compress data 

e¢ L—Data compression is determined by the speed specified on the line description. “Data 
Compression” on page E-1 has more information about data compression. 


Default: L 


WAITFILE Maximum This field contains the number of seconds that the program waits for the Intersystem Communications 
file wait time Function (ICF) file resources to be allocated when the file is opened. 


Length: 6 characters 
Type: Input, not required 


Valid values are as follows: 
— 000001 through 032767 seconds in character format (leading zeros are required) 
— *IMMED 
- *CLS 


Default: 000030 


AS/400 System Retrieving a File from 
System/36 


Figure E-6 describes the required parameters for retrieving a 
file from System/36. 
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Figure E-6 (Page 1 of 2). AS/400 System Retrieving a File from System/36—Required Parameters 


Parameter Value Description 
OPTION Char- File transfer option to perform. 
acter 


Length: 1 character 
Type: Input, required 
Valid values are as follows: 


¢ S—Send. Refer to “AS/400 System Sending to System/36” on page E-6. This section describes only 
retrieve. 
¢ R—Retrieve a file from the remote System/36. 


FROMLIB Blanks Not needed in retrieving a file from System/36. 
Length: 10 characters 
Type: Not applicable 
Valid values: Blanks 
FROMFILE File Name of the System/36 file. 
hame Length: 10 characters (see note at the end of this figure) 
Type: Input, required 
Valid values: System/36 file name 
FROMMBR Blanks Not needed in retrieving a file from System/36. 
Length: 10 characters 
Type: Not applicable 
Valid values: Blanks 


TYPE File This field contains the date of the file to retrieve. Make sure that the system date format on the target system 
type is the same as the format on your system. 


Length: 6 characters 

Type: Input, not required 

Valid values: Numeric date 

Default: If no date is given, the most recent file is retrieved. 


TOLIB Target The name of the receiving library. 
library Length: 10 characters 
name 
Type: Input, not required 
Valid values: Library name 
Default: The System/36 environment default library name. 
TOFILE Target Name of the receiving database file. 
file Length: 10 characters 
name 
Type: Input, not required 
Valid values: File name 
Default: FROMFILE 
TOMBR Target Name of the receiving member. 
ale Length: 10 characters 
member 
name Type: Input, not required 


Valid values: Member name 


Default: If the name is not given, the member name is the date given in TODATE or the creation date with an 
M added as the first character. 


When using TOMBR, consider the following: 


¢ If you are replacing a member (REPLACE=Y), TOMBR is the name of the member to replace at the 
target system. 


¢ If you are adding a new member, TOMBR is the name to assign. 
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Figure E-6 (Page 2 of 2). AS/400 System Retrieving a File from System/36—Required Parameters 


Parameter Value Description 
TODATE Numeric _ This field gives a different date to a file received from a System/36. Make sure that the system date format 
on the target system is the same as the format on your system. 
Length: 6 characters 
Type: Input, not required 
Valid values: Numeric date 
REPLACE Char- This field tells whether you want to replace the member. 
acts! Length: 1 character 
Type: Input, not required 
Valid values: 
e Y—Replace an existing member. 
¢ N—Do not replace an existing member. 
Default: N 
If you specify REPLACE=Y for a member, you cannot use the database file containing that member for any 
other operation during the replace operation. 
RMTLOCNAME Location Name of the remote location with which you are communicating. 
Name Length: 8 characters 
Type: Input, required 
Valid values: Remote location name in a varied-on device description. 
PASSWORD Pass- Password for signing on the remote system. 
word Length: 10 characters. The largest password System/36 accepts is 4 characters. 
Type: Input. This field is required only if the remote system has password security active. 
Valid values: Password 
RTNCODE Char- This field contains the return code. FTS returns this value to the application program to indicate the result of 
acter the transfer. 
Length: 1 character 
Type: Output 
Valid values: 
¢ OQ —Normal completion. 
¢ 1—An error was detected at the local system. 
e¢ 2—An error was detected at the remote system. 
For return codes 1 and 2, the specific error is logged to the history file of the System/36 and to the job log file 
of the AS/400 system. The message-id is returned to the user in the message-id field. (See “File Transfer 
Support Messages” on page E-34 for more information.) 
MESSAGE-ID Char- This field contains the message-id for the specific error if the value returned in the RTNCODE field is 1 or 2 
acter (indicating an error). 


Length: 8 characters 
Type: Output 


Valid values: Any message-id listed in the message section. (See “File Transfer Support Messages” on 
page E-34 for more information.) 


Note: Ifa library name, file name, or member name is greater than 8 characters, System/36 uses the first 8 characters as the name. 


Figure E-7 describes the optional parameters for receiving a 
file from System/36. 
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Figure E-7. Retrieving Files from System/36—Optional Parameters 


Parameter Value Description 


RMTNETID Remote This field contains the network ID of the network where the remote location resides. 
network 


: 2 Length: 8 characters 
identifier 


Type: Input, not required 
Valid values are as follows: 


e¢ Remote network ID 
¢ *LOC 

¢ *NETATR 

e *NONE 


Default: *LOC 
MODE Mode name This field contains the mode name used. 
Length: 8 characters 
Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *NETATR 


Default: *NETATR 


LCLLOCNAME Local This field contains the local location name. 
location 


Length: 8 characters 
name 


Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *LOC 
¢ *NETATR 


Default: *LOC 


COMPRESS Com- Indicates if data compression will be done. 
pression 


Lene Length: 1 character 
indicator 


Type: Input, not required 
Valid values are as follows: 


¢ Y—Compress data 

¢ N—Do not compress data 

¢ L—Data compression is determined by the speed specified on the line description. “Data 
Compression” on page E-1 has more information about data compression. 


Default: L 


WAITFILE Maximum This field contains the number of seconds that the program waits for the Intersystem Communications 
file wait time Function (ICF) file resources to be allocated when the file is opened. 


Length: 6 characters 
Type: Input, not required 


Valid values are as follows: 
— 000001 through 032767 seconds in character format (leading zeros are required) 
— *IMMED 
- *CLS 


Default: 000030 


Retrieving a Library Member from 
System/36 


Figure E-8 describes the required parameters for retrieving a 
library member from System/36. 
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Figure E-8 (Page 1 of 2). Retrieving a Library Member from System/36—Required Parameters 


Parameter Value Description 
OPTION Char- File transfer option to perform. 
acter Length: 1 character 
Type: Input, required 
Valid values are as follows: 
e S—Send. Refer to “AS/400 System Sending to System/36” on page E-6. This section describes only 
retrieve. 
e R—Retrieve a library member. 
FROMLIB Library Name of the library in which library member resides. 
name Length: 10 characters (see note) 
Type: Input, required 
Valid values: System/36 library name 
FROMFILE Blanks Not needed in retrieving a library member from System/36. 
Length: 10 characters 
Type: Not applicable 
Valid values: Blanks 
FROMMBR Library Name of the library member. 
member Length: 10 characters (see note) 
name 
Type: Input, required 
Valid values: System/36 member name 
TYPE Library This field tells System/36 the type of member to retrieve. 
member Length: 6 characters 
type 
Type: Input, required 
Valid values: SOURCE, LOAD, PROC (procedure), SUBR (subroutine) 
TOLIB Library Name of the receiving library to which members are sent. 
nas. Length: 10 characters 
Type: Input, not required 
Valid values: Library name 
Default: FROMLIB 
TOFILE Target Name of the file. 
ile Length: 10 characters 
name 
Type: Input, not required 
Valid values: Database file name 
Default: If no value is given, the default name is determined by the type of the member, as follows: 
¢ Source—QS36SRC 
e« Load—QS36LOD 
e Procedure—QS36PRC 
¢ Subroutine—QS36SBR 
TOMBR Target Name of the member at the target system. 
member Length: 10 characters 
name 


Type: Input, not required 

Valid values: Member name 

Default: FROMMBR 

When you use TOMBR, consider the following: 


¢ If you are replacing a member (REPLACE=Y), TOMBR is the name of the member to replace at the target 
system. 


e If you are adding a new member, TOMBR is the name to assign. 
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Figure E-8 (Page 2 of 2). Retrieving a Library Member from System/36—Required Parameters 


Parameter Value Description 
TODATE Blanks Not needed in retrieving a library member from System/36. 
Length: 6 characters 
Type: Input, not applicable 
Valid values: Blanks 
REPLACE Char- This field tells whether you want to replace the member on the target system. 
acter Length: 1 character 
Type: Input, not required 
Valid values: 
e Y—Replace an existing member. 
e N—Do not replace an existing member. 
Default: N 
If you specify REPLACE=Y for a member, you cannot use the file containing that member for any other opera- 
tion during the replace operation. 
RMTLOCNAME Location Name of the remote location with which you are communicating. 
Name Length: 8 characters 
Type: Input, required 
Valid values: Remote location name in a varied-on device description. 
PASSWORD PASS- Password for signing on the remote system. 
WORD Length: 10 characters. The largest password System/36 accepts is 4 characters. 
Type: Input. This field is required only if the remote system has password security active. 
Valid values: Password 
RTNCODE Char- This field contains the return code. FTS returns this value to the application program to indicate the result of 
acter the transfer. 
Length: 1 character 
Type: Output 
Valid values: 
¢ 0—Normal completion. 
e¢ 1—An error was detected at the local system. 
e 2—An error was detected at the remote system. 
For return codes 1 and 2, the specific error is logged to the history log of the System/36 and to the job log file 
of the AS/400 system. The message-id is returned to the user in the message-id field. (See “File Transfer 
Support Messages” on page E-34 for more information.) 
MESSAGE-ID Char- This field contains the message-id for the specific error if the value returned in the RTNCODE field is 1 or 2 
acter (indicating an error). 


Length: 8 characters 
Type: Output 


Valid values: Any message-id listed in the message section. (See “File Transfer Support Messages” on 
page E-34 for more information.) 


Note: If a library name, file name, or member name is greater than 8 characters, System/36 uses the first 8 characters as the name. 


Figure E-9 describes the optional parameters for retrieving a 
library member from System/36. 
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Figure E-9. Retrieving a library member from System/36—Optional Parameters 


Parameter 


Value 


Description 


RMTNETID 


MODE 


LCLLOCNAME 


COMPRESS 


WAITFILE 


Remote 
network 
identifier 


Mode name 


Local 
location 
name 


Com- 
pression 
indicator 


Maximum 
file wait time 


This field contains the network ID of the network where the remote location resides. 


Length: 8 characters 
Type: Input, not required 
Valid values are as follows: 


¢ Remote network ID 
¢ *LOC 

¢ *NETATR 

e *NONE 


Default: *LOC 

This field contains the mode name used. 
Length: 8 characters 

Type: Input, not required 

Valid values are as follows: 


¢ Mode name 
¢ *NETATR 


Default: *NETATR 


This field contains the local location name. 


Length: 8 characters 
Type: Input, not required 
Valid values are as follows: 


¢ Mode name 
¢ *LOC 
¢ *NETATR 


Default: *LOC 


Indicates if data compression will be done. 


Length: 1 character 
Type: Input, not required 
Valid values are as follows: 


¢ Y—Compress data 
¢ N—Do not compress data 


e¢ L—Data compression is determined by the speed specified on the line description. “Data 
Compression” on page E-1 has more information about data compression. 


Default: L 


This field contains the number of seconds that the program waits for the Intersystem Communications 
Function (ICF) file resources to be allocated when the file is opened. 


Length: 6 characters 
Type: Input, not required 
Valid values are as follows: 


— 000001 through 032767 seconds in character format (leading zeros are required) 


— *IMMED 
— *CLS 


Default: 000030 
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Calling File Transfer Support for the ILE C 
Programming Language 


Figure E-10 is an example of a ILE C program that provides 
a data link between one AS/400 system and another AS/400 
system. This program reads the file in which the parameters 
are stored, calls the file transfer support program 

(QY2FTML), and prints a listing of the parameters, return 


code, and message number. 


MOdUIEG: 2: Sotchive ®t le Sha east 

LDR ARV > oo sek em Sn oe ore ge dase ey ey 
SOUPCE: -FITE wes 6 ep eee es eS 

LEEDRARV ssp cero crates Bret “ec Sarees 
Source member .........3 
Text Description 
Output 
Compiler options 


Checkout options .......: 
Optimization 
Inline options: 


TM TANOP F652 Gr ced eS a Ge AE 
Mode 


LA eee se sore 2S! 23p ee She. Ge SE 
Debugging view 
Define names 
Language level 
Source margins: 

Left margin. ........32 

Right margin 
Sequence columns: 

Left Colum .......4..:3 

Right Column 
Message flagging level 
Compiler messages: 

Message limit. .......3: 

Message limit severity 
Replace program object 
AUTHOR UEY" ore Se- estes? “sae Poet ee Sates 
Target release 
System includes ........3: 
Last change... .......2: 
Source description 


kK KK KK 
CDRIVER 
KPSLIB 
QCSRC 
KPSLIB 
CDRIVER 


*PRINT 
*NOAGR = *NOEXPMAC 
*NOSHOWINC 
*NOACCURACY = *NOENUM 
*NOPARM  *NOPORT 
*NONE 


*OFF 
*NOAUTO 
250 
2000 
*NONE 


*SOURCE 


1 
32754 


) 


*NOMAX 

30 

*YES 

*LIBCRTAUT 
*CURRENT 

*YES 

06/08/94 12:56:15 


Conipi Ver: =: ete ek, ae ees tee. 0 IBM ILE C/400 Compiler 
KKK KK 
Line STMT 
1 |#pragma linkage(QY2FTML,OS) /* 
2 
3 |#define END 1 /* 
4 |#define NOEND 0 
5 |#define ERROR 1 /* 
6 |#define NOERROR @ 
7 |#include <stdio.h> /* 
8 |#include <stdlib.h> /* 
9 |#include <stddef.h> /* 
10 |#include <string.h> /* 
1 | 


*GEN 
*NOSHOWSKP 


*NOPPCHECK 


PROLOG 


kK kK KK 


*LOGMSG 
*NOXREF 
*NOEXTERN 


*NOPPONLY 
*USRINCPATH 
*NOGENERAL 
*NOPPTRACE 


*NOSECLVL 


*NOGOTO 


SOURCE ***** 

Define program to be called */ 
Signals program end */ 

Signals an error during I/0 */ 
Standard 1/0 header */ 

General utilities */ 


Standard definitions */ 
String handling utilities */ 


Figure E-10 (Part 1 of 7). ILE C Coding for File Transfer Support 
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*NOINIT 


The parameters passed to the file transfer program are 
described in “File Transfer Parameters” on page E-3. 


SEQNBR 
1 


rFPOWOON A OF WP 


Pe 


INCNO 


OBBRBRRRR ER EH 
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on 
ee 


52 


an 
Fw 


|/* Define header structures to be written to the print file. */ 
FS ame aae te Ou Rant Came tite fea toe tee oilieees sete +/ 
struct { 


char filler??(124??); 
} header_line_l = { 

"FRMLIB ” 
"FRMFIL . 
"FRMMBR m 
"TYPE " 
"TOLIB i 
"TOFIL 
"TOMBR " 
"TODATE " 
"OPTION " 
"REPL " 
"RMTLOC " 
"RCODE " 
"MSGNUM  " 


struct { 
char filler??(124??); 
} header_line_2 = { 


* Define data file structure that contains the values to be assigned +*/ 
* to parameters passed on call to program QY2FTML. */ 


char rec_num??(3??); 
char option; 
char repl; 
char fillerl??(4??); 
char frmlib??(10??); 
char frmfil??(10??); 
char frmmbr??(10??); 
char typ??(6??); 
char filler2??(4??); 
char tolib??(10??); 
char tofil??(10??); 
char tombr??(10??); 
char todate??(6??); 
char filler3??(4??); 
char rmtloc??(8??) ; 
char passwd??(10??); 
char rcode; 
char msgnum?? (8??) ; 
} call_rec; 
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80 | [an 2 on nnn nn nn nnn nnn enn ne nnn nnn nnn nn nnn nnn nnn nnn ne nnn nnn een nnn n ee x/ | 80 
81 |/* Define the structure types of the parameters on call to QY2FTML. The */ | 81 
82 |/* type definition is needed for prototyping. x*/ | 82 
83 | [a= - 2-2 nnn nn nnn nnn nnn nnn nnn nnn nn nn nnn nnn nnn nnn nen ne nn nee x/ | 83 
84 | | 84 
85 |typedef struct { | 85 
86 | char option; | 86 
87 |} option; | 87 
88 | | 88 
89 |typedef struct { | 89 
90 | char frmlib??(10??); | 90 
91 |} libs | 91 
92 | | 92 
93 |typedef struct { | 93 
94 | char frmfil??(10??); | 94 
95 |} files | 95 
96 | | 96 
97 |typedef struct { | 97 
98 | char frmmbr??(10?7) ; | 98 
99 |} file_member; | 99 
100 | | 100 
101 [typedef struct { | 101 
102 | char typ??(6??); | 102 
103 |} types | 103 
104 | | 104 
105 |typedef struct { | 105 
106 | char tolib??(10??); | 106 
107 |} tgt_lib; | 107 
108 | | 108 
109 |typedef struct { | 109 
110 | char tofil??(10??); | 110 
111 |} tgt_file; | 111 
112 | | 112 
113 |typedef struct { | 113 
114 | char tombr??(10??) ; | 114 
115 |} tgt_member; | 115 
116 | | 116 
117 |typedef struct { | 117 
118 | char todate??(6??) ; | 118 
119 |} tgt_file_date; | 119 
120 | | 120 
121 |typedef struct { | 121 
122 | char repl; | 122 
123 |} replace_member; | 123 
124 | | 124 
125 |typedef struct { | 125 
126 | char rmtloc??(8??) ; | 126 
127 |} rmt_loc; | 127 
128 | | 128 
129 |typedef struct { | 129 
130 | char passwd??(10??) ; | 130 
131 |} pword; | 131 
132 | | 132 
133 |typedef struct { | 133 
134 | char rcode; | 134 
135 |} ret_code; | 135 
136 | | 136 
137 |typedef struct { | 137 
138 | char msgnum??(8??); | 138 
139 |} msg_num; | 139 
140 | | 140 


Figure E-10 (Part 3 of 7). ILE C Coding for File Transfer Support 
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Figure E-10 (Part 4 of 7). ILE C Coding for File Transfer Support 


|/* a ee ee Ee a ne ee ee 


[struct { 

| char prec_num??(3??); 
| char fillerl1??(2??); 
| char pfrmlib??(10??); 
| char filler2; 

| char pfrmfil??(10??); 
| char filler3; 

| char pfrmmbr??(10??); 
| char filler4; 

| char ptyp??(6??); 

| char filler5??(3??); 
| char ptolib??(10??); 
| char filler6; 

| char ptofil??(10??); 
| char filler7; 

| char ptombr??(10??); 
| char fillers; 

| char ptodate??(6??); 
| char filler9??(5??); 
| char poption; 

| char filler10??(5??); 
| char prep]; 

| char filler11??(3??); 
| char prmtloc??(8??); 
| char filler12??(3??); 
| char prcode; 

| char filler13??(3??); 
| char pmsgnum??(8??); 
|} print_rec; 

| 
| 
| 
| 
| 
| 


* type definitions already defined. 


|option option_parm; 

|1ib 1ib_parm; 

|file file_parm; 

| file_member file_member_parm; 

| type type_parm; 

|tgt_lib tgt_lib_parm; 
|tgt_file tgt_file_parm; 
|tgt_member tgt_member_parm; 
|tgt_file_date tgt_file_date_parm; 
|replace_member replace_member_parm; 


|rmt_loc rmt_loc_parm; 
| pword pword_parm; 

|ret_code ret_code_parm; 
|msg_num msg_num_parm; 


|char op_name??(5??); 


extern void QY2FTML(option *, lib *, file *, file_member *, type *, 


replace_member *, rmt_loc *, pword *, ret_code *, 


/* Current operation */ 


* Declare structures to use as parameters on call to QY2FTML using the */ 


*/ 


| 
| tgt_lib *, tgt_file *, tgt_member *, tgt_file date *, 
| 
| 


msg_num *); 
Jint print_header(FILE *); 
int file_trans(FILE *); 
|void init_parms(void); 
[int print_parms(FILE *); 
|int pos_ret_code_printf (void); 
|void print_file_error(void); 
|void close _files(FILE *, FILE *); 


Re 
BS 
OnNanFPWwNhrre 


a 
—N 
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FILE *dtafptr; /* Pointer to the database file */ 
FILE *prtfptr; /* Pointer to the printer file */ 


if ((dtafptr = fopen("FTTEST", "rb type=record")) == NULL) { 


| 
| 
| 
| 
| 
2 | printf ("\nUNEXPECTED ERROR WHILE OPENING DATA FILE.\n"); 
3 | exit (ERROR) ; 
i. 
4 | if ((prtfptr = fopen("QSYSPRT", "wb type=record")) == NULL) { 
5 | fclose(dtafptr) ; 
6 | printf ("\nUNEXPECTED ERROR WHILE OPENING PRINT FILE.\n"); 
7 | exit (ERROR) ; 
} 
8 | if (print_header(prtfptr) == NOERROR) { 
9 | while (1) { 
10 | if (file_trans(dtafptr) == END) 
11 | break; 
| else 
12 | if (print_parms(prtfptr) == ERROR) { 
13 | print_file_error(); 
14 | close_files(dtafptr, prtfptr); 
15 | exit (ERROR) ; 
| } 
| } 
lis a 
| else { 
16 | print_file_error(); 
17 | close _files(dtafptr, prtfptr); 
18 | exit (ERROR) ; 
| } 
19 | close_files(dtafptr, prtfptr); 
20 | exit (NOERROR) ; 
|} 
| 
| 
|/* Gesebinesocee secs eeec cco sans epececetonsaeeencceecoebeoscctowescsaeeece 
|/* The routine prints a header to the print file 
|/* ees ee EE ee ee ee eee ee ae 
| 
|print_header(FILE *prtfptr) 
l{ 
1 | strcpy(op_name, "WRITE"); 
2 | fwrite(&header_line_1, sizeof(header_line_1), 1, prtfptr); 
3a if (pos_ret_code_printf() == NOERROR) { 
4 | fwrite(&header_line_2, sizeof(header_line_2), 1, prtfptr); 
5 | return(pos_ret_code_printf()); 
| } 
| else 
6 | return (ERROR) ; 
| 
| 
| 


Figure E-10 (Part 5 of 7). ILE C Coding for File Transfer Support 


E-20 


ICF Programming V4R1 


209 


ine} 
i 
fas) 


262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
280 
281 
282 
283 
284 
285 
286 
287 
288 
289 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
308 
309 
310 
311 
312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 


ine) 


OnNanFPWDNYrFe 


OnNanFPWDMYre 


(Pease SL Goan Seco te eu seu en eon ede eo cee */ 
|file_trans(FILE *dtafptr) 

[{ 

| int len; 

| 

| strcpy(op_name, "READ "); 

| if ((len = fread(&call_rec, sizeof(call_rec), 1, dtafptr)) == 0) 

| return(END) ; 

| else { 

| init_parms(); 

| QY2FTML(&option_parm, &lib_parm, &file_parm, &file_member_parm, 

| &type_parm, &tgt_lib_parm, &tgt_file_parm, &tgt_member_parm, 
| &tgt_file_date_parm, &replace_member_parm, &rmt_loc_parm, 
| &pword_parm, &ret_code_parm, &msg_num_parm) ; 

| return (NOEND) ; 

| } 

|} 

| 

| 

| [t----------- 222-222-222 2-222 n eee */ 
|/* This routine initializes the parameters for the call to QY2FTML. */ 


|/* Parameters passed to external programs in C/400 must be a structure */ 
|/* type, so the fields of the structure call_rec may not be sent indiv- */ 
|/* idually to QY2FTML. */ 
| [a= - 2-2 nnn nn nnn enn nnn nnn nn nnn nn nnn nnn nnn nnn nee nn nee x/ 


|void init_parms() 

I{ 

option_parm.option = call_rec.option; 
strcpy(lib_parm.frmlib, call_rec.frmlib); 
strcpy(file_parm.frmfil, call_rec.frmfil); 
strcpy(file_member_parm.frmmbr, call_rec.frmmbr) ; 
strcpy(type_parm.typ, call_rec.typ); 
strcpy(tgt_lib_parm.tolib, call_rec.tolib); 
strcpy(tgt_file_parm.tofil, call_rec.tofil); 
strcpy(tgt_member_parm.tombr, call_rec.tombr); 
strcpy(tgt_file_date_parm.todate, call_rec.todate) ; 
replace_member_parm.repl = call_rec.repl; 
strcpy(rmt_loc_parm.rmtloc, call_rec.rmtloc); 
strcpy(pword_parm.passwd, call_rec.passwd) ; 
ret_code_parm.rcode = ' '; 
strcpy(msg_num_parm.msgnum, " "ys 


} 


print_parms(FILE *prtfptr) 
{ 


strncpy(print_rec.prec_num, call_rec.rec_num, 3); 
print_rec.poption = call_rec.option; 

print_rec.prepl = call_rec.rep1; 
strncpy(print_rec.pfrmlib, lib_parm.frmlib, 10); 
strncpy(print_rec.pfrmfil, file_parm.frmfil, 10); 
strncpy(print_rec.pfrmmbr, file_member_parm.frmmbr, 10); 
strncpy(print_rec.ptyp, type_parm.typ, 6); 
strncpy(print_rec.ptolib, tgt_lib_parm.tolib, 10); 
strncpy(print_rec.ptofil, tgt_file_parm.tofil, 10); 
strncpy(print_rec.ptombr, tgt_member_parm.tombr, 10); 
strncpy(print_rec.ptodate, tgt_file date _parm.todate, 6); 
strncpy(print_rec.prmtloc, rmt_loc_parm.rmtloc, 8); 
print_rec.prcode = ret_code_parm.rcode; 
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329 14 | strncpy(print_rec.pmsgnum, msg_num_parm.msgnum, 8); 
330 15 | strncpy(print_rec.fillerl, " ", 2); 
331 16 | strncpy(print_rec.filler5, " ", 3); 
332 17 | strncpy(print_rec.filler9, " ", 5)s 
333 18 | strncpy(print_rec.fillerlo, " ", 5)3 
334 19 | strncpy(print_rec.fillerll, "| ", 3); 
335 20 | strncpy(print_rec.fillerl2, " "i 3)'s 
336 21 | strncpy(print_rec.filler13, "|", 3); 
337 | print_rec.filler2 = print_rec.filler3 = print_rec. filler 
338 22 | = print_rec.filler6 = print_rec.filler7 = print_rec.fill 
339 23 | strcpy(op_name, “WRITE"); 
340 24 | fwrite(&print_rec, sizeof(print_rec), 1, prtfptr); 
341 25 | return(pos_ret_code_printf()); 
342 |} 
343 | 
344 | 
345 | [enn nnn nnn nnn nnn nnn nn nnn nnn enn nnn nnn nnn nnn nnn enn ene 
346 |/* This routine checks to see if the last operation on the p 
347 |/* was successful. 
348 | [tonne nnn - nn nn nn nn nnn nn nnn nn ene eee eee 
349 | 
350 |pos_ret_code_printf() 
351 l{ 
352 1 | if (strncmp(_Maj_Min_rc.major_rc, "00", 2) == NOERROR) 
353 2 | return (NOERROR) ; 
354 | else 
355 3 | return (ERROR) ; 
356 |} 
357 | 
358 | 
359 | [tenn nn nnn enn nnn nn nn nn nn enn enn nnn nnn nnn nnn enn enn enn nee 
360 |/* This routine prints an error message to the display. 
361 | [een nn n-- 2-2 2-2 no-no nnn nen eee 
362 | 
363 |void print_file_error() 
364 l{ 
365 1 | printf ("\nUNEXPECTED ERROR ON %s FOR PRINT FILE\n", 
366 |} 
367 | [tenn n nnn nnn nnn nn nn nnn nnn enn nnn nnn nnn nnn nnn ene enn 
368 |/* Close the data and print files. 
369 | [tonne nnn - nn nn nn no non nnn nnn nnn eee eee eee 
370 | 
371 |void close_files(FILE *dtafptr, FILE *prtfptr) 
372 l{ 
373 1 | fclose(dtafptr) ; 
374 2 | fclose(prtfptr) ; 
375 |} 
376 | 
**e*e*e** END OF SOU 
kK kk OK INCLUDES 
INCNBR Include Name Last change Actual Includ 
1 stdio.h 04/19/94 14:18:08 QCLE/H/STDIO 
2  stdlib.h 04/19/94 14:18:09 QCLE/H/STDLIB 
3. stddef.h 04/19/94 14:18:07 QCLE/H/STDDEF 
4 string.h 04/19/94 14:18:09 QCLE/H/STRING 
kk kk OK END OF INCLU 
ee eee MESSAGE SUM 
Total Informational (00) Warning (10) 
0 0 ) 


**e*e*e* END OF MESSAGE 
Module CDRIVER was created in library KPSLIB on 06/08/94 at 12:57:06. 
**e*e*e** END OF COMPIL 
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The parameters passed to the file transfer program are 
described in “File Transfer Parameters” on page E-3. 


Calling File Transfer Support for 
COBOL/400 Programming Language 


Figure E-11 is an example of a COBOL/400 program that 
provides a data link between one AS/400 system and 
another AS/400 system. This program reads the file in which 
the parameters are stored, calls the file transfer support 
program (QY2FTML), and prints a listing of the parameters, 
return code, and message number. 


Program . 2... 1. ee ee ee et )~©)© COBDRIVER 
LIDPANY” se oe sé ee A ES eS KPSLIB 
SOURCE TIT Eo. ee sted ar kn eo ae eed QCBLSRC 
BADRANY™ oe. emer a Bae ee oe ee a a ae KPSLIB 
Source member ........... :  COBDRIVER 05/05/89 09:23:28 
Generation severity level .....: 29 
Text ‘description’. ........:  *SAME 
Source listing options. ......:  ¥*NONE 
Generation options. ........:  *NONE 
Print File ns ee ees ce, eo wee /QSYSPRT. 
EPDRANY™ See caf ce oes 2a Sb 158 core Gat, aR Se sgh FE *LIBL 
FIPS flagging ........... :  ¥*NOFIPS *NOSEG *NODEB *NOOBSOLETE 
SAA flagging. ........... =: + *NOFLAG 
Flagging severity .........: 0 
Replace program ..........: ~~ «¥*YES 
Target release. . 2... ... ~~. 3) *CURRENT 
User profile. ........... :  *USER 
Authority ......... 4... =. :  *LIBCRTAUT 
Compiler. ......... 4.4... 2. IBM COBOL/400 
1 000100 IDENTIFICATION DIVISION. 11/04/87 
2 000200 PROGRAM-ID. QY2FTML. 11/04/87 
3 000300 AUTHOR. EAPOE. 11/04/87 
000400* 11/04/87 
4 ©00500 ENVIRONMENT DIVISION. 11/04/87 
5 00600 CONFIGURATION SECTION. 11/04/87 
6 000700 SOURCE-COMPUTER. IBM-AS400. 05/04/89 
7 000800 OBJECT-COMPUTER. IBM-AS400. 05/04/89 
8 000900 INPUT-OUTPUT SECTION. 11/04/87 
9 001000 FILE-CONTROL. 11/04/87 
10 001100 SELECT SEQ-FILE ASSIGN TO DISK-FTTEST 01/29/88 
11 001200 ORGANIZATION IS SEQUENTIAL 11/04/87 
12 001300 FILE STATUS IS SEQ-FILE-STATUS. 05/04/89 
001400* 11/04/87 
13 001500 SELECT SYSPRT ASSIGN TO PRINTER-QSYSPRT, 01/29/88 
14 001600 ORGANIZATION IS SEQUENTIAL 01/29/88 
15 001700 ACCESS IS SEQUENTIAL 05/04/89 
16 001800 FILE STATUS IS PRINT-FILE-STATUS. 05/04/89 
001900* 01/29/88 
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Figure 


E-24 


002000 DATA DIVISION. 
002100 FILE SECTION. 
SEQ-FILE LABEL RECORDS ARE STANDARD. 


002200 FD 
002300 01 
002400 
002500* 
002600 FD 
002700 
002800 
002900* 
003000 01 
003100 
003200* 


003300 WORKING-STORAGE SECTION. 


003400 77 
003500 77 
003600 77 
003700 77 
003800 77 
003900 77 
004000* 
004100 01 
004200 
004300* 
004400 01 
004500 
004600 
004700 
004800 
004900 
005000 
005100 
005200 
005300 
005400 
005500 
005600 
005700 
005800 
005900« 
006000 01 
006100 
006200 
006300 
006400 
006500 
006600 
006700 
006800 
006900 
007000 
007100 
007200 
007300 
007400 
007500« 
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SEQ-FILE-REC. 
02 FILLER 


SYSPRT 


PIC X(101). 


LABEL RECORDS ARE OMITTED 


LINAGE IS 80 LINES. 


PRINT-FILE-REC. 


@2 FILLER PIC X(132). 


SEQ-FILE-STATUS 
PRINT-FILE-STATUS 
OP-NAME 

ERRORFLAG 

EOF 

EOF-FLAG 


ERRORFLAG 
88 ERROR-OCCURED 


HEADER-LINE-1. 
03 FILLER 
03 FROM-LIBRARY 

03 FROM-FILE 

03 FROM-MEMBER 

03 OBJ-TYPE 

03 TO-LIBRARY 

03 TO-FILE 

03 TO-MEMBER 

03 TO-DATE 

03 OPTN 

03 REPLCE 

03 REMOTE-LOCATION 
03 RETURN-CODE 

03 MESSAGE-NUMBER 


HEADER-LINE-2. 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 
03 FILLER 


ICF Programming V4R1 


PIC 
PIC 
PIC 
PIC 
PIC 
PIC 


PIC 


X(2). 

X(2). 

X(7). 

X VALUE SPACES. 
X VALUE SPACES. 
X VALUE "1". 


X VALUE SPACES. 


VALUE "1". 


PIC 
PIC 
PIC 
PIC 
PIG 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 


PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 
PIC 


X(5) VALUE SPACES. 
X(11) VALUE "FRMLIB 
X(11) VALUE "FRMFIL 
X(11) VALUE "FRMMBR 
X(9) VALUE "TYPE 

X(11) VALUE "TOLIB 
X(11) VALUE "TOFIL 
X(11) VALUE "TOMBR 
X(9) VALUE "TODATE 
X(7) VALUE "OPTION 


X(5) VALUE "REPL ". 


X(9) VALUE "RMTLOC 
X(6) VALUE "RCODE 


X(7) VALUE "MSGNUM ". 


X(5) VALUE SPACES. 
X(11) VALUE " 
X(11) VALUE " 
X(11) VALUE " 
X(9) VALUE " 
X(11) VALUE " 
X(11) VALUE " 
X(11) VALUE " 
X(9) VALUE " 
X(7) VALUE " 


X(5) VALUE " or 


X(9) VALUE " 
X(6) VALUE " 
X(8) VALUE " 


11/04/87 
11/04/87 
11/04/87 
11/04/87 
11/04/87 
01/29/88 
01/29/88 
02/01/88 
02/01/88 
02/02/88 
11/04/87 
11/04/87 
02/02/88 
11/04/87 
01/29/88 
01/29/88 
11/04/87 
01/29/88 
01/29/88 
01/29/88 
02/02/88 
01/29/88 
01/29/88 
02/02/88 
02/01/88 
02/01/88 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/02/88 
02/01/88 
02/01/88 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/01/89 
02/02/88 


66 007600 01 CALL-REC. 11/04/87 


007700* RECORD NUMBER 02/01/88 
67 007800 @2 REC-NUM PIC X(3). 02/01/88 
007900* OPTION 02/01/88 
68 008000 02 OPTION PIC X(1). 02/01/88 
008100* REPLACE MEMBER 02/01/88 
69 008200 02 REPL PIC X(1). 02/01/88 
008300* BLANKS 02/01/88 
70 008400 02 FILLER PIC X(4). 02/01/88 
008500* LIBRARY NAME 02/01/88 
71 008600 02 FRMLIB PIC X(10). 02/01/88 
008700* FILE NAME 02/01/88 
72 008800 02 FRMFIL PIC X(10). 02/01/88 
008900* FILE MEMBER 02/01/88 
73 009000 02 FRMMBR PIC X(10). 02/01/88 
009100* TYPE 02/01/88 
74 009200 02 TYP PIC X(6). 02/01/88 
009300* BLANKS 02/01/88 
75 009400 02 FILLER PIC X(4). 02/01/88 
009500* TARGET LIBRARY NAME 11/04/87 
76 009600 02 TOLIB PIC X(10). 02/01/88 
009700* TARGET FILE/LIBRARY NAME 11/04/87 
77 009800 02 TOFIL PIC X(10). 02/01/88 
Q09900* TARGET FILE/LIBRARY MEMBER NAME 11/04/87 
78 010000 02 TOMBR PIC X(10). 02/01/88 
010100* TARGET FILE DATE 11/04/87 
79 010200 02 TODATE PIC X(6). 02/01/88 
010300* BLANKS 02/01/88 
80 010400 02 FILLER PIC X(4). 02/01/88 
010500* REMOTE LOCATION 02/01/88 
81 010600 02 RMTLOC PIC X(8). 02/01/88 
010700* PASSWORD 11/04/87 
82 010800 02 PASSWD PIC X(10). 02/24/89 
010900* RETURN CODE 11/04/87 
83 6011000 02 RCODE PIC X(1). 02/24/89 
011100* MESSAGE NUMBER 02/01/88 
84 611200 02 MSGNU PIC X(8). 11/04/87 
011300* 02/02/88 
85 011400 01 PRINT-REC. 02/01/88 
011500* PRINT RECORD NUMBER 02/01/88 
86 011600 @2 PREC-NUM PIC X(3). 02/01/88 
011700* BLANKS 02/01/88 
87 611800 02 FILLER PIC X(2). 02/01/88 
011900* PRINT LIBRARY NAME 02/01/88 
88 012000 @2 PFRMLIB- PIC X(10). 02/01/88 
012100* BLANKS 02/02/88 
89 012200 02 FILLER PIC X(1). 02/02/88 
012300* FILE NAME 02/02/88 
90 012400 @2 PFRMFIL PIC X(10). 02/02/88 
012500* BLANKS 02/02/88 
91 012600 02 FILLER PIC X(1). 02/02/88 
012700* FILE MEMBER 02/02/88 
92 012800 @2 PFRMMBR- PIC X(10). 02/02/88 
012900* BLANKS 02/02/88 
93 613000 02 FILLER PIC X(1). 02/02/88 
013100* TYPE 02/02/88 
94 013200 02 PTYP PIC X(6). 02/02/88 
013300* BLANKS 02/02/88 
95 013400 02 FILLER PIC X(3). 02/02/88 
013500* TARGET LIBRARY NAME 02/02/88 
96 013600 02 PTOLIB PIC X(10). 02/02/88 
013700* BLANKS 02/02/88 
97 013800 02 FILLER PIC X(1). 02/02/88 
013900* TARGET FILE/LIBRARY NAME 02/02/88 
98 014000 02 PTOFIL PIC X(10). 02/02/88 
014100* BLANKS 02/02/88 
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99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
112 


113 


114 
115 
116 


117 
118 
119 


120 
121 
122 
123 
124 
125 


126 
127 
128 


129 
130 


Figure 
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014200 


02 FILLER PIC X(1). 


014300* TARGET FILE/LIBRARY MEMBER NAME 


014400 
014500* B 
014600 


014700* TARGET FILE DATE 


014800 
014900* B 
015000 
015100* P 
015200 
015300* B 
015400 
015500* P 
015600 
015700* B 
015800 
015900* R 
016000 
016100* B 
016200 
016300* R 
016400 
016500* B 
016600 
016700* M 
016800 
016900* 


02 PTOMBR PIC X(10). 
LANKS 
02 FILLER PIC X(1). 


02 PTODATE PIC X(6). 


LANKS 

02 FILLER PIC X(5). 
RINT OPTION 

02 POPTION PIC X(1). 
LANKS 


02 FILLER PIC X(5). 
RINT REPLACE MEMBER 

02 PREPL PIC X(1). 
LANKS 
02 FILLER PIC X(3). 
EMOTE LOCATION 
@2 PRMTLOC PIC X(8). 
LANKS 
02 FILLER PIC X(3). 
ETURN CODE 
02 PRCODE PIC X(2). 
LANKS 
02 FILLER PIC X(2). 
ESSAGE NUMBER 
@2 PMSGNUM PIC X(8). 


017000 PROCEDURE DIVISION. 


017100 DEC 


LARATIVES. 


O17 200 kx KAA K KAKA EKER RRR RRR ERR RRR KERR KERR KER ERE RERE RRR 


017300* SEQUENTIAL DECLARATIVE SECTION 


017400* 


O17 5 OD KKK KKK KAA KK KKK RRR KEK RRR KER KER RRR ERR ERK RR REERRERE RRR 


017600 I-0 
017700 
017800 I-0 
017900 
018000 
018100 


-ERROR-SEQ SECTION. 

USE AFTER STANDARD ERROR PROCEDURE ON SEQ-FILE. 
-ERROR-PARA-SEQ. 

DISPLAY "UNEXPECTED ERROR ON ", OP-NAME, "FOR SEQ FILE". 
DISPLAY "FILE STATUS IS " SEQ-FILE-STATUS. 

SET ERROR-OCCURED TO TRUE. 


OLB 200 kx xR KAKA KAKA EKER EKER RRR RRR ERR RK RRR KERR KERR RE REE ERREREER 


018300* PR 
018400* 


INTER FILE DECLARATIVE SECTION 


O1L85 O00 kx xR KKK KAA KKA KK RRR KEK RRR KERR KERR KERR RRR ERE RR RRR RERERRERER 


018600 I-0 
018700 
018800 I-0 
018900 
019000 
019100 
019200 END 
019300« 


-ERROR-PRINT SECTION. 
USE AFTER STANDARD ERROR PROCEDURE ON SYSPRT. 
-ERROR-PARA-PRINT. 


DISPLAY "FILE STATUS IS ", PRINT-FILE-STATUS. 
SET ERROR-OCCURED TO TRUE. 
DECLARATIVES. 


019400 MAIN-PROGRAM SECTION. 
019500 MAIN-PROCEDURE. 


019600 
019700 
019800 
019900 
020000 
020100 
020200* 
020300 FIL 
020400 
020500 
020600 
020700 
020800 
020900 
021000* 


E-11 (Part 


PERFORM OPEN-FILES. 

PERFORM HDR-PRT. 

PERFORM READ-REC. 

PERFORM FILE-TRANS UNTIL EOF = EOF-FLAG. 
PERFORM CLOSE-FILES. 

STOP RUN. 


E-TRANS. 

MOVE SPACES TO MSGNUM. 

MOVE SPACES TO RCODE. 

CALL "QY2FTML" USING OPTION FRMLIB FRMFIL FRMMBR TYP TOLIB 
TOFIL TOMBR TODATE REPL RMTLOC PASSWD RCODE MSGNUM. 
PERFORM PRINT-PARAMETERS. 

PERFORM READ-REC. 
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DISPLAY "UNEXPECTED ERROR ON ", OP-NAME, " FOR PRINT FILE". 


02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/01/88 
02/01/88 
02/02/88 
02/02/88 
02/01/88 
02/01/88 
02/02/88 
02/02/88 
02/01/88 
02/02/88 
02/02/88 
02/02/88 
02/01/88 
02/02/88 
02/02/88 
02/02/88 
02/01/88 
02/02/88 
02/02/88 
11/04/87 
11/04/87 
05/04/89 
05/04/89 
05/04/89 
05/04/89 
11/04/87 
11/04/87 
11/04/87 
05/04/89 
05/04/89 
11/04/87 
05/04/89 
05/04/89 
05/04/89 
05/04/89 
11/04/87 
01/29/88 
11/04/87 
11/09/87 
11/09/87 
11/04/87 
11/04/87 
02/02/88 
11/04/87 
11/04/87 
02/01/88 
02/01/88 
05/04/89 
01/29/88 
11/04/87 
11/04/87 
02/02/88 
11/04/87 
11/09/87 
11/09/87 
02/01/88 
02/01/88 
11/09/87 
05/04/89 
05/04/89 


021100 READ-REC. 


131 021200 MOVE "READ" TO OP-NAME. 

132 021300 READ SEQ-FILE INTO CALL-REC 

133 021400 AT END MOVE EOF-FLAG TO EOF. 

134 021500 IF ERROR-OCCURED GO TO ERROR-TERMINATION. 
021600* 
021700 PRINT-PARAMETERS. 

136 021800 OVE REC-NUM TO PREC-NUM. 

137 021900 MOVE OPTION TO POPTION. 

138 022000 OVE REPL TO PREPL. 

139 022100 OVE FRMLIB TO PFRMLIB. 

140 022200 OVE FRMFIL TO PFRMFIL. 

141 022300 OVE FRMMBR TO PFRMMBR. 

142 022400 OVE TYP TO PTYP. 

143 022500 OVE TOLIB TO PTOLIB. 

144 022600 MOVE TOFIL TO PTOFIL. 

145 022700 OVE TOMBR TO PTOMBR. 

146 022800 OVE TODATE TO PTODATE. 

147 022900 OVE RMTLOC TO PRMTLOC. 

148 023000 OVE RCODE 10 PRCODE. 

149 023100 OVE MSGNUM TO PMSGNUM. 

150 023200 OVE "WRITE" TO OP-NAME. 

151 023300 WRITE PRINT-FILE-REC FROM PRINT-REC. 

152 023400 IF ERROR-OCCURED GO TO ERROR-TERMINATION. 
023500* 
023600 HDR-PRT. 

154 023700 MOVE "WRITE" TO OP-NAME. 

155 023800 WRITE PRINT-FILE-REC FROM HEADER-LINE-1. 

156 023900 WRITE PRINT-FILE-REC FROM HEADER-LINE-2. 

157 024000 IF ERROR-OCCURED GO TO ERROR-TERMINATION. 
024100* 
024200 OPEN-FILES. 

159 024300 MOVE "OPEN" TO OP-NAME. 

160 024400 OPEN I-0 SEQ-FILE, 
024500 OUTPUT SYSPRT. 

161 024600 IF ERROR-OCCURED GO TO ERROR-TERMINATION. 
024700* 


024800 CLOSE-FILES. 


163 024900 MOVE "CLOSE" TO OP-NAME. 

164 025000 CLOSE SEQ-FILE SYSPRT. 

165 025100 IF ERROR-OCCURED GO TO ERROR-TERMINATION. 
025200* 


025300 ERROR-TERMINATION. 


167 025400 DISPLAY "I-O0 ERROR OCCURED - PROCESS TERMINATION". 
168 025500 STOP RUN. 
**e*e*e*e END OF SOURCE ** * * * 
ee *e* * END OF MESSAGES * * * * * 
Message Summary 
Total Info(0-4) Warning(5-19) Error (20-29) Severe (30-39) Terminal (40-99) 
) 0 0 ) 0 0 
Source records read... .....3: 255 
Copy records read... .. 2... 2.3? 0 
Copy members processed ......: 0 
Sequence errors. .........3: 0 


Highest severity message issued ..: 0 
LBLO901 00 Program COBDRIVER created in library KPSLIB. 
ee *e** END OF COMPILATION 
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kK kK KKK 


05/04/89 
05/04/89 
05/04/89 
05/04/89 
05/04/89 
02/02/88 
11/09/87 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/02/88 
02/01/88 
02/02/88 
11/09/87 
02/02/88 
02/01/88 
02/01/88 
02/01/88 
02/01/88 
02/01/88 
02/02/88 
11/09/87 
11/09/87 
11/09/87 
01/29/88 
11/09/87 
02/02/88 
11/09/87 
11/09/87 
01/29/88 
11/09/87 
02/02/88 
11/09/87 
11/09/87 
11/09/87 
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The parameters passed to the file transfer are described in 
“File Transfer Parameters” on page E-3. 


Calling File Transfer Support for RPG/400 
Programming Language 


Figure E-12 is an example of an RPG/400 program that pro- 
vides a data link between one AS/400 system and another 
AS/400 system. The program shown reads the file in which 
the parameters are stored, calls the file transfer support 
program (QY2FTML), and prints a listing of the parameters, 
return code, and message number. 


Compiler. ............ =: IBM RPG/400 
Command Options: 
PrOGY al 6.6 Sei es KPSLIB/RPGDRIVER 
Source FIVE eee we ee a we KPSLIB/QRPGSRC 
Source member .........3 RPGDRIVER 
Source listing options .....: *SOURCE *XREF *GEN *NODUMP *NOSECLVL 
Generation options .......: *NOLIST *NOXREF *NOATR *NODUMP *NOOPTIMIZE 
Source listing indentation... :  »*NONE 
SAA flagging... 2... ...03 *NOFLAG 
Generation severity level 9 
Print fie: sd ac! ce te at Geko a a ae ok *LIBL/QSYSPRT 
Replace program ........: *YES 
Target release. . 2... 2... 23: *CURRENT 
User profile. .........: *USER 
Authority. -.0 Ge a See ar GR *LIBCRTAUT 
MOXA seo ask termi AA sts Geel ote 28 Ee Ge *SRCMBRTXT 
Phase trace .......... : ~~ ¥NO 
Intermediate text dump ..... :  “*NONE 
Snap dump ........... :  *NONE 
Codelist:.. 6 non. Soa a ee Be © *NONE 
Ignore decimal data error ...:  ¥*NO 
Actual Program Source: 
Member .......... +... :  RPGDRIVER 
EG nd. pe elo pic cine tec Teh RE, eee QRPGSRC 
LET DVANY! 0 Ge Sie ee ce eet eG eS a KPSLIB 
Last Change ..........3 03/01/89 14:10:21 
Description .........-.: *SAME 
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100 
200 
300 
400 
500 
600 
700 
800 
* 4137 

900 
1000 
1100 
1200 
1300 
1400 
1500 
1600 
1700 
1800 
1900 
2000 
2100 
2200 
2300 
2400 
2500 
2600 
2700 
2800 
2900 
3000 
3100 
3200 
3300 
3400 
3500 
3600 
3700 
3800 
3900 
4000 
4100 


4200 
4300 
4400 
4500 
4600 
4700 
4800 
4900 
5000 
5100 
5200 
5300 
5400 
5500 
5600 
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H 


* SAMPLE PROGRAM TO READ A RECORD, THEN CALL PROGRAM 


Source 


Listing 


*  'QY2FTML' TO TRANSFER MEMBER, REPEAT UNTIL LAST 


* RECORD, THEN PRINT LISTING. 
IP F 


FFTTEST 


FQSYSPRT 0 


I* 


IFTTEST NS 
4137-** 


* 


DODD DAD DDDADDD DD DDD OHHH HHH eee 


C* 
OQSYSPRT H 
0 OR 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 H 


QYLIST 


1 


1 


120 
0132 


1P 


OF 


1P 


PLIST 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 
PARM 


DISK 
PRINTER 


OPTION 1 
FRMLIB 10 
FRMFIL 10 
FRMMBR 10 
TYPE 6 
TOLIB 10 
TOFIL 10 
TOMBR 10 
TODATE 6 
REPL 1 
RMTLOC 8 
PASSWD 10 
RCODE 1 
MSGNUM 8 


CALL 'QY2FTML' QYLIST 


11 'FRMLIB' 
22 'FRMFIL' 
33 'FRMMBR' 
42 'TYPE' 
52 'TOLIB' 
63 'TOFIL' 
74 'TOMBR' 
86 'TODATE' 
95 'OPTION' 
101 'REPL 
107 'RMTLOC' 
116 'RCODE 
122 'MSGNUM' 


INDEX 
OPTION 
REPL 
FRMLIB 
FRMFIL 
FRMMBR 
TYPE 
TOLIB 
TOFIL 
TOMBR 
TODATE 
RMTLOC 
PASSWD 


11/03/87 
02/23/89 
02/23/89 
02/23/89 
11/10/87 
02/23/89 
11/03/87 
11/11/87 


11/12/87 
02/23/89 
11/12/87 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
11/03/87 
11/11/87 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
11/03/87 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
11/03/87 
11/11/87 
11/03/87 
02/23/89 


02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
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5700 
5800 
5900 
6000 
6100 
6200 
6300 
6400 
6500 
6600 
6700 
6800 
6900 
7000 
7100 
7200 
7300 
7400 
7500 
7600 
7700 
7800 
7900 
8000 
8100 
8200 
8300 
8400 
8500 
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Additional 
RPG PROVIDES BLOCK OR UNBLOCK SUPPORT FOR FILE FTTEST. 
oss Reference 


* 7086 500 


Cr 


File and Record References: 


FILE/RCD 
01 FITTEST 
02 QSYSPRT 


Field References: 
FIELD 
FRMFIL 
FRMLIB 
FRMMBR 
INDEX 
MSGNUM 
OPTION 
PASSWD 
QYLIST 
RCODE 
REPL 
RMTLOC 
TODATE 
TOFIL 
TOLIB 
TOMBR 
TYPE 
"QY2FTML' 


DEV/R 
DISK 
PRINT 


ATTR 
A(10) 
A(10) 
A(10) 
A(3) 
A(8) 
A(1) 
A(10) 
PLIST 
A(1) 
A(1) 
A(8) 
A(6) 
A(10) 
A(10) 
A(10) 
A(6) 


CD 


ER 


OF 


1P 


INDEX 
FRMLIB 
FRMFIL 
FRMMBR 
TYPE 
TOLIB 
TOFIL 
TOMBR 
TODATE 
OPTION 
REPL 
RMTLOC 
RCODE 
MSGNUM 
OF SOURCE ** * * * 


Diagnostic 


~N 
wo 


REFERENCES (D=DEFINED) 
500D 800 
600D 4100 5600 7100 


REFERENCES (M=MODIFIED D=DEFINED) 


1 
1 
1 


3 
1 
2 
2 
3 
1 
2 
1 
1 
d 
1 
1 


300D 2600D 
200D 2500D 
400D 2700D 
900D 7200 

700D 8500 

000D 2400D 
100D 3500D 
300D 3900M 
600D 8400 

100D 3300D 
000D 3400D 
900D 3200D 
700D 3000D 
600D 2900D 
800D 3100D 
500D 2800D 


LITERAL 3900 


Indicator References: 
INDICATOR REFERENCES (M=MODIFIED D=DEFINED) 


LR 
OF 
1P 


KKK KK 


500D 


600D 4200 5700 
4100 5600 7100 


END 


OF 


CROS 


7400 
7300 
7500 


8100 


8200 
8300 
8000 
7800 
7700 
7900 
7600 


Ss 


REFERENCE 


Messages 
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02/23/89 
11/12/87 
11/12/87 
11/12/87 
11/12/87 
11/12/87 
11/12/87 
11/12/87 
11/12/87 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 
02/23/89 


Message Summary 


* QRG4137 Severity: 00 Number: 1 

Message... .?: Record-Identifying-Indicator entry is blank. 
* QRG7086 Severity: 00 Number: 1 

Message . . . . : RPG handles blocking function for file. INFDS 


updated only when blocks of data transferred. 
**e*e**e** END OF MESSAGE SUMMARY ** * * * 
Final 
Message Count: (by Severity Number) 
TOTAL 00 10 20 30 40 50 


Summary 


2 2 0 0 0 0 ) 
Program Source Totals: 
Records... 66 ee ee es BS 
Specifications ......: 78 
Table Records .......: 0 
Comments .......4..3: 7 


PRM has been called. 


Program RPGDRIVER is placed in library KPSLIB. 00 highest Error-Severity-Code. 


***** END OF COMPILATION 
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user then has the option to submit the database member as 
a batch job or end the program. 


Calling File Transfer Support for a CL 
Program 


Figure E-13 is an example of a CL program that uses file 
transfer support to retrieve a database member from a 
remote system and store it in the library QTEMP. The 
program uses the Display Physical File Member (DSPPFM) 
command which allows the user to view the member. The 


Program... 1. ee ee ee ee ee ew ee et) SBMRMTJOB 
ET DAR Ys. seca tele a Stheste e. ey ke, ete ae Se ee KPSLIB 
SOURCE PATS se. oe es te ad ele Set inc Ded te cia! ate wet He es ee ue SE QCLSRC 
LET DANY) tex eatin: 108 ee, ences gecet ernest es wae ee KPSLIB 
Source member name ............ . =: SBMRMTJOB 03/21/89 10:15:10 
Source printing options ........... :  ¥*SOURCE *XREF *GEN *NOSECLVL 
Program generation options .........:  *NOLIST *NOXREF *NOPATCH 
User profile ............6+.. 4. :  *USER 
Program logging... ...... 2... est = *JOB 
Allow RTVCLSRC command ...........: ~~ «¥*YES 
Replace program. ........2.4244246 62: ~ *YES 
Target release . 2... 1... ee ee ee ee 2) XCURRENT 
AUCHOL It se oe ee eee ee ed we ee ee“ -— *ETBERTAUT 
TEX: Sheds Hoe ees ah ae a Xa ME & Retrieves a member from a remote sys and SBMDBJOB 
COMPP LEY gy .h sire. Hor Bay ei ee nd Gay ee eae ee IBM AS/400 Control Language Compiler 


Control Language Source 
SEQNBR: ese sti.cs. Lt Gantte tech Ree Ose hacer Ae seein Oo eithis fOr tetany eanthiateO eSehegs 9 «eee “DATE 

100- 

200- [ BIKAR RRR KIKI KIRK KAKI KIRK KAKI KIRK KAKI K IK IKEA KI KIRKE ARAKI KIER AKA | 

300- /* This program uses File Transfer Support to retrieve a data base */ 01/24/89 
400- /* member from a remote system and store it in library QTEMP. The */ 

500- /* Display Physical File Member(DSPPFM) command is then used to */ 

600- /* allow the user to view the member. When the user is finished */ 

700- /* viewing the member "enter" is pressed to continue. An inquiry */ 

800- /* message is then sent to the user which allows their choice */ 

900- /* whether or not to submit this member as a batch job. Ifa "Y" x/ 01/24/89 
1000- /* response is given the Submit Data Base Job(SBMDBJOB) command is */ 

1100- /* used to submit the job to batch. If a "N" response is given */ 


1200- /* the program ends. */ 

1300- [BRK I RARER KIKI KIRK KIKI KIRK A KI KIRK KIKI K IKK KAKI KIRKE ARIK REK ERK AK | 

1400- 

1500- PGM PARM(&FROMLIB &FROMFILE &FROMMBR) 

1600- DCL VAR(&FROMLIB) TYPE(*CHAR) LEN(10) 

1700- DCL VAR(&FROMFILE) TYPE(*CHAR) LEN(10) 

1800- DCL VAR(&FROMMBR) TYPE(*CHAR) LEN(10) 

1900- DCL VAR(&PASSWORD) TYPE(*CHAR) LEN(10) 02/24/89 
2000- DCL VAR(&RTNCODE) TYPE(*CHAR) LEN(1) VALUE(' ') 

2100- DCL VAR(&SBMJOB) TYPE(*CHAR) LEN(1) 01/24/89 
2200- 

2300- [BIKAR IRR RR KIKI KIRKE AKI KIRK KAKI KIRKE AKI KI KIKI KIKI KIRA KARE | 

2400- /* Retrieve user's password from a data area. */ 01/24/89 
2500- /* (used to preserve security). */ 

2600- [BIKAR IR RR KAKI K EKER KIKI KIRKE AKI KI KEKE IKI KI KIKI KIKI KEKE ARAKI | 

2700- RTVDTAARA DTAARA(PASSWORD (1 10)) RTNVAR(&PASSWORD) 02/24/89 
2800- 01/24/89 
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2900- [ BIKAR RRR KIKI KER ER KAKI KIRK KAR IK IKKE A KIKI KIKI KAKI KEKE AKA KI | 
3000- /* Retrieve the member from the remote system using File */ 
3100- /* Transfer Support. Note the call to File Transfer is */ 
3200- /* made with both CL variables and constant values. Also */ 
3300- /* note that File Transfer parameters are all positional. */ 
3400- /* You must, therefore, reserve space in the call for all */ 
3500- /* 14 parameters. If a parameter is not used, fill its */ 
3600- /* space with blanks. */ 
3700- [ BIKA RR RIKI KIKI ERK I KI KIRKE AK IKI KEKE AKA KI KEKE AKIRA KEKE AKA KE | 
3800- CALL PGM(QSYS/QY2FTML) PARM(R &FROMLIB + 

3900 &FROMFILE &FROMMBR ' ' QTEMP ' - 
4000-—C | ' “a " Y RCHAS365 &PASSWORD &RTNCODE ' ') 
4100- [BIKAR RRR KAKI KERR KAKI KIRK KAKI K IKKE AKI KIK EKA KAKI KEKE AKA KI | 
4200- /* Check the FTS return code to insure a good completion. */ 
4300- [BIKAR RRR KIKI KER ER KAKI KIRK KIKI RIK IK KAKI K IK IKEA KAKI KEKE AKA KE | 
4400- IF COND(&RTNCODE *EQ '0') THEN(DO) 

4500- 

4600- [BIKAR RR RR KIKI K ER ER KAKI KEK ER KAKA KIRKE AK IKI KEKE AKA KIRKE AKA KEK | 
4700- /* Display the member. */ 
4800- [BIKAR KR KAKI KERR KAKI KIRK KIKI KI KER KAKI KI KIEK KAKA KEKE REIKI KER | 
4900- DSPPFM FILE(QTEMP/&FROMFILE) MBR(&FROMMBR) 

5000- 

5100- [ BIKAR IR RR KA KIKI ER KAKI KIRK KIKI KI KEKE A KIKI KIKI KIKI KEKE AKA KE | 
5200- /* Send the inquiry message to the user. */ 
5300- [BIKAR RRR KIKI KERR KAKI KIRK KAKI K IKK KAKI KI KEKE AKI KIRKE ARAKI | 
5400- SNDUSRMSG MSG('Submit the job to batch (Y,N)') VALUES(Y + 
5500 N) DFT(Y) MSGRPY (&SBMJOB) 

5600- 

5700- [ BIKAR IRR KIKI KERR KAKI K IK IR KAKI KIRK KAKI KIER IK KAKI K IKE REIKI KE | 
5800- /* Check the user's response. If it is "Y", submit the job */ 
5900- /* to batch using the Submit Data Base Job(SBMDBJOB) command.+*/ 
6000- /* If the response is "N", return to caller. */ 
6100- [ BIKAR RRR KIKI KER ER KAKI KEK IK EA KIKI KIRA KAKI KIKI KAKI KERIKERI | 
6200- IF COND(&SBMJOB *EQ 'Y') THEN(SBMDBJOB + 

6300 FILE(QTEMP/&FROMFILE) MBR(&FROMMBR) ) 
6400- 

6500- ENDDO /* FTS return code is good */ 

6600- ENDPGM 


eee ee END OF SOURCE **%%% 


Cross Reference 
Declared Variables 


01/24/89 


03/21/89 
03/21/89 
03/21/89 


01/24/89 
01/24/89 
01/24/89 
03/21/89 
01/24/89 


01/24/89 
01/24/89 
01/24/89 
01/24/89 
01/24/89 


01/24/89 
03/21/89 


Name Defined Type Length References 

&FROMFILE 1700 *CHAR 10 1500 3800 4900 6200 
&FROMLIB 1600 *CHAR 10 1500 3800 

&FROMMBR 1800 *CHAR 10 1500 3800 4900 6200 
&PASSWORD 1900 *CHAR 10 2700 3800 

&RTNCODE 2000 *CHAR 1 3800 4400 

&SBMJOB 2100 *CHAR 1 5400 6200 
* CPDO791 00 No labels used in program. 

ee ee * END OF CROSS REFERENCE ** * * * 
* CPDO772 00 Program contains commands only valid when run interactively. 
Message Summary 
Severity 
Total 0-9 10-19 20-29 30-39 40-49 50-59 60-69 70-79 80-89 90-99 
2 2 ) 0 ) ) 0 0 ) 0 0 
Program SBMRMTJOB created in library KPSLIB. Maximum error severity 00. 
**e*e** END OF MESSAGE SUMMARY * * * * * 
ee *e* * END OF COMPILATION ** * * * 
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File Transfer Support Messages 


File Transfer Support messages give more information about 
the error condition that occurred on either the local or remote 
system. The FTS message number itself is available to the 
application through the Message-ID parameter. The FTS 
message is logged in the program message queue of the 
program using FTS and contains a description of the error 
that occurred. 


If a local system error occurs, the FTS message directly 
identifies the error that occurred. 


If a remote system error occurs, FTS-1007 will be logged in 
the program message queue. The actual remote system 
error is identified in the message text associated with 
FTS-1007, and returned to the program in the Message-ID 
parameter. If the remote system is a AS/400 system, you 
need to examine the message text of the system message 
associated with the remote FTS message. The correlation 
between the system message ID and the FTS message ID 
are described below. If the remote system is a System/36, 
the remote FTS message ID is described in the Using S/36 
Communications book. 


Figure E-14 (Page 7 of 2). File Transfer Messages 


FTS Message ID System Message ID 


System Message Description 


FTS-1001 CPI7A01 File transfer support started. 

FTS-1002 CPI7A02 File transfer support ended. 

FTS-1003 CPD7A03 File transfer support ended with remote location because of an error. 
FTS-1004 CPD7A04 File transfer support could not be started. 

FTS-1005 CPD7A05 File transfer support canceled by system operator. 
FTS-1006 CPD7A06 Permanent session error occurred while communicating with remote location. 
FTS-1007 CPD7A07 Remote system error. 

FTS-1008 CPD7A08 Required number of parameters not specified. 
FTS-1009 CPD7A09 User ID not authorized to remote location. 

FTS-1010 CPI7A10 Received member from remote location. 

FTS-1011 CPI7A11 Member sent to remote location. 

FTS-1012 CPD7A12 Error receiving member from remote location. 
FTS-1013 CPD7A13 Error sending member to remote location. 

FTS-1014 CPF7A14 File transfer support has ended abnormally. 
FTS-1019 CPD7A19 Remote location not available. 

FTS-1020 CPD7A20 Option code not valid. 

FTS-1021 CPD7A21 Database file name not valid. 

FTS-1022 CPD7A22 Library name not valid. 

FTS-1023 CPD7A23 File data not valid. 

FTS-1024 CPD7A24 Member type not valid. 

FTS-1025 CPD7A25 Member name not valid. 

FTS-1026 CPD7A26 Replace option not valid. 

FTS-1027 CPD7A27 Cannot sent System/36 folder. 

FTS-1028 CPD7A28 Cannot replace folder. 

FTS-1030 CPD7A30 System/36 file already exists. 

FTS-1031 CPD7A31 System/36 file or library member in use. 

FTS-1032 CPD7A32 Not enough storage to receive member. 

FTS-1033 CPD7A33 System/36 VTOC is full. System/36 file cannot be created. 
FTS-1034 CPD7A34 User not authorized to access file in library. 
FTS-1035 CPD7A35 Error occurred while creating file or member in library. 
FTS-1036 CPD7A36 File in library not found. 

FTS-1037 CPD7A37 System/36 file cannot be opened. 

FTS-1038 CPD7A38 Disk error while opening System/36 file. 

FTS-1039 CPD7A39 Cannot send System/36 library. 
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FTS Message ID 


System Message ID 


System Message Description 


FTS-1040 
FTS-1041 
FTS-1042 
FTS-1043 
FTS-1044 
FTS-1046 
FTS-1049 
FTS-1050 
FTS-1051 
FTS-1052 
FTS-1053 
FTS-1054 
FTS-1055 
FTS-1056 
FTS-1057 
FTS-1058 
FTS-1059 
FTS-1060 
FTS-1063 
FTS-1064 
FTS-1065 
FTS-1066 
FTS-1067 
FTS-1068 
FTS-1069 
FTS-1070 
FTS-1071 
FTS-1072 
FTS-1073 


CPD7A40 
CPD7A41 
CPD7A42 
CPD7A43 
CPD7A44 
CPD7A46 
CPD7A49 
CPD7A50 
CPD7A51 
CPD7A52 
CPD7A53 
CPD7A54 
CPD7A55 
CPD7A56 
CPD7A57 
CPD7A58 
CPD7A59 
CPD7A60 
CPD7A63 
CPD7A64 
CPD7A65 
CPD7A66 
CPD7A67 
CPD7A68 
CPD7A69 
CPD7A70 
CPD7A71 
CPD7A72 
CPD7A73 


Cannot send database logical file in library. 
Disk error while creating System/36 file. 
Disk error while reading System/36 file. 
Member in file in library is full. 


Member record length does not match file definitions record length in library. 


System/36 dictionary or definition not found in System/36 file. 
System/36 file exists as a remote file. 

Library not found. 

User not authorized to access library. 

Member already exists. 

Member not found. 

Not enough space in library to create member. 

System/36 directory full. Cannot create member in library. 
Member is in use. 

Object in library is an IBM-supplied object. 

Disk error while opening member. 


Disk error while closing library member. 


Mode in network attributes not specified in device for remote location. 


File in library is not a physical file. 

Member in file in library record length too long. 

Cannot receive externally defined file. 

Required parameters incorrectly specified. 

Maximum record length too small. 

TYPE parameter value does not match attributes of file in library. 
Transparent mode required. 


Error occurred while attempting to establish session with remote location. 


TYPE parameter value not valid for file. 
File wait time not valid. 


Data compression option not valid. 
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Bibliography 


The following books contain information you may need. The 
books are listed with their full title and order number. Except 
where otherwise indicated, each is an AS/400 system book. 


Communications Books 


APPN Support, SC41-5407, provides the information 
necessary to define and use the AS/400 system 
Advanced Peer-to-Peer Networking (APPN) function. 
This book contains information on both ICF and 
Common Programming Interface (CPI) Communications. 


APPC Programming, SC41-5443, provides the applica- 
tion programmer with information about the advanced 
program-to-program communications (APPC) support 
provided by the AS/400 system. This book is a guide for 
developing application programs and for defining the 
communications environment for APPC communications. 
This book contains information on both ICF and 
Common Programming Interface (CPI) Communications. 


DSNX Support, SC41-5409, contains information about 
preparing a system for remote management activities 
and about using the change management feature distrib- 
uted systems node executive (DSNX). 


Asynchronous Communications Programming, 
SC41-5444, provides the application programmer with 
information for creating an asynchronous communica- 
tions definition, writing programs that use asynchronous 
communications, and responding to return codes. It also 
provides information on developing asynchronous com- 
munications application programs that use ICF. 


BSC Equivalence Link Programming, SC41-5445, pro- 
vides the application programmer or programmer with 
the information needed to write programs that use binary 
synchronous communications equivalence link (BSCEL) 
to communicate with a remote system. It also contains 
information for programmers about other systems and 
devices that communicate with BSCEL on the AS/400 
system. The book describes how to set up BSCEL and 
how to run application programs that use BSCEL. 


Finance Communications Programming, SC41-5449, 
provides information for the application programmer or 
system administrator who uses the OS/400 finance 
support for financial communications between devices at 
multiple locations. It describes how finance support 
communicates with a controller and how to set up 
finance support. This book provides information for 
writing application programs to communicate with appli- 
cation programs on the finance controller using ICF. 


Intrasystem Communications Programming, SC41-5447, 
provides the application programmer or programmer with 
information about interactive communications between 
two application programs on the same AS/400 system. 
This book also provides information on developing intra- 
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system communications application programs that use 
ICF. 


Communications Management, SC41-5406, provides the 
system operator or programmer with information on 
using AS/400 communications such as work manage- 
ment, communications status, error handling, aggregate 
line speed and subsystem storage. 


Communications Configuration, SC41-5401, contains 
information for configuring objects for communications. 


Remote Job Entry (RJE) Guide, SC09-1903, provides 
information for using the Communications Utilities 
remote job entry (RJE) to submit jobs to an IBM host 
processor. 


Retail Communications Programming, SC41-5448, pro- 
vides information for setting up and starting retail com- 
munications between devices at multiple locations. 


SNA Upline Facility Programming, SC41-5446, contains 
information on using the Systems Network Architecture 
Upline Facility with the IBM AS/400 system. 


Sockets Programming, SC41-5422, provides information 
for using the sockets programming interface for the 
AS/400 system. 


3270 Device Emulation Support, SC41-5408, provides 
information on setting up and starting 3270 device emu- 
lation using binary synchronous communications (BSC) 
or Systems Network Architecture (SNA) communications. 


Application Display Programming, SC41-5715, provides 
information about: 


— Using DDS to create and maintain displays for appli- 
cations; 

— Creating and working with display files on the 
system; 

— Creating online help information; 

— Using UIM to define panels and dialogs for an appli- 
cation; 

— Using panel groups, records, or documents 


System API Reference, SC41-5801, provides user- 
defined communications information for the AS/400 
system. 


TCP/AP Configuration and Reference, SC41-5420, pro- 
vides information on TCP/IP configurations, IBM-supplied 
applications, and user-written applications. 


Programming Language Books 


DDS Reference, SC41-5712, contains information about 
coding data description specifications for physical, 
logical, display, printer, and ICF files. 


Data Management, SC41-5710, provides information to 
help the system programmer manage key aspects of the 
system. For example, it describes how to use diskette 
and tape files. 


H-2 


DB2 for AS/400 Database Programming, SC41-5701, 
provides information about the AS/400 database man- 
agement system, and describes how to set up and use a 
database on the AS/400 system. 


Distributed Data Management, SC41-5307, contains the 
information needed to use DDM on a network. It 
includes AS/400 system DDM concepts, preparing for 
DDM communications, and all DDM-related program- 
ming information needed by the DDM programmer. 


Printer Device Programming, SC41-5713, provides infor- 
mation to help the programmer manage key aspects of 
the system. For example, it describes how to use printer 
files. 


ILE COBOL/400 Reference, SC09-2073, provides a 
description of the ILE COBOL language organization, 
program organization, procedure division statements, 
and compiler directing statements. 


ILE COBOL/400 Programmer's Guide, SCO09-2072, Pro- 
vides information about how to write, compile, bind, run, 
debug, and maintain ILE COBOL/400 programs on the 
AS/400 system. 


COBOL/400 User's Guide, SC09-1812, provides the 
information needed to write, test and maintain 
COBOL/400 programs for the AS/400 system. 


ILE RPG/400 Reference, SC09-2077, provides informa- 
tion about the ILE RPG programming language. This 
manual describes, position by position and keyword by 
keyword, the valid entries for all RPG IV* specifications, 
and provides a detailed description of all the operation 
codes and built-in functions. 


ILE RPG/400 Programmer’s Guide, SC09-2074, provides 
information about the ILE RPG programming language, 
including information on creating and running programs. 
RPG/400 User’s Guide, SC09-1816, provides the infor- 
mation needed to use the RPG/400 programming lan- 
guage to code programs for the AS/400 system. 
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ILE C/400 Programmer's Reference, SC09-2070, pro- 
vides information about how to write programs that 
adhere to the Systems Application Architecture C Level 
2 definition and use ILE C/400 specific functions such as 
record I/O. 


ILE C/400 Programmer's Guide, SC09-2069, provides 
the information needed to use the ILE C programming 
language to code programs for the AS/400 system. 


CL Programming, SC41-5721, provides a wide-ranging 
discussion of AS/400 system programming topics. 


CL Reference, SC41-5722, provides information on 
control language commands. 


ILE Concepts, SC41-5606, explains concepts and termi- 
nology pertaining to the Integrated Language Environ- 
ment (ILE) architecture of the OS/400 licensed program. 
Topics covered include creating modules, binding, 
running programs, debugging programs, and handling 
exceptions. 


Work Management, SC41-5306, contains information on 
how to create and change a work management environ- 
ment. 


Security — Reference, SC41-5302, contains information 
about general security concepts for the system. 


System Operation, SC41-4203, provides information for 
the system operator on how to use the system unit 
control panel. 


System/36-Related Books 


System/36 System Reference, SC21-9020, contains 
information on System/36 naming conventions you might 
need for file transfer support (FTS). 


Using S/36 Communications, SC21-9082, contains infor- 
mation on the correlation between system message IDs 
and File Transfer Support message IDs on the 
System/36. 


Index 


Special Characters 
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ADDCMNE (Add Communications Entry) command 8-5 
ADDICFDEVE (Add Intersystem Communications Func- 
tion Program Device Entry) command 4-7 
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sending error signal example 7-10 
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COBOL/400 program 7-10 
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command 8-5 
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Device Entry (CHGICFDEVE) command 
description 4-2 
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Change Prestart Job (CHGPJ) command 8-8 
Change Prestart Job Entry (CHGPJE) command 8-8 
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CHGPJE (Change Presiart Job Entry) command 8-8 
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CICS/VS (Customer Information Control System for 
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CIMENU (Casual Inquiry menu) 10-35, 11-36 
CL (control language) 
See also command, CL 
acquire example 3-5 
file transfer support (FTS) example E-32 
introduction 2-4 
close considerations 8-3, 8-4 
close operation 5-17 


closing an ICF file 5-17 
CMNTYPE (communications type) parameter 
use 4-15 
values 4-15 
CNLINVITE (cancel-invite) keyword 6-16 
COBOL/400 programming language 
DDS for display file (DSPFIL) 10-34 
display file 10-25, 10-32 
ending 
sessions 7-19 
transactions 7-17 
error handling 10-1 
fail function 7-8, 7-9 
feedback areas 10-2 
file transfer example E-23 
indicating error conditions 7-8 
interface 10-1 
introduction 10-1 
output operations 7-4 
request-to-write 7-13, 7-15 
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data 7-4 
negative-responses 7-11 
command type 
file-level attribute 4-2 
for ICF files 4-2 
information display 4-2 
program device entry 4-2 
relationship between ICF commands 4-15 
command, CL 
Add Communications Entry (ADDCMNE) 8-5 
Add Intersystem Communications Function Program 
Device Entry (ADDICFDEVE) 4-2, 4-7 
Add Prestart Job Entry (ADDPJE) 8-8 
Add Routing Entry (ADDRTGE) 8-5 
ADDCMNE (Add Communications Entry) 8-5 
ADDICFDEVE (Add Intersystem Communications Func- 
tion Program Device Entry) 4-2, 4-7, 4-10 
ADDPJE (Add Prestart Job Entry) 8-8 
ADDRTGE (Add Routing Entry) 8-5 
Change Communications Entry (CHGCMNE) 8-5 
Change Intersystem Communications Function File 
(CHGICFF) 4-2, 4-5 
Change Intersystem Communications Function Program 
Device Entry (CHGICFDEVE) 4-2, 4-7 
Change Prestart Job (CHGPJ) 8-8 
Change Prestart Job Entry (CHGPJE) 8-8 
Check Object (CHKOBJ) 8-9 
CHGCMNE (Change Communications Entry) 8-5 
CHGICFDEVE (Change Intersystem Communications 
Function Program Device Entry) 4-2, 4-7 
CHGICFF (Change Intersystem Communications Function 
File) 4-2, 4-5 
CHGPJ (Change Prestart Job) 8-8 
CHGPUJE (Change Prestart Job Entry) 8-8 
CHKOBu (Check Object) 8-9 
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Create Class (CRTCLS) 8-12 RMVPJE (Remove Prestart Job Entry) 8-8 
Create Subsystem Description (CRTSBSD) 8-5 RTVCFGSTS (Retrieve Configuration Status) B-3 
CRTCLS (Create Class) 8-12 RTVDTAARA (Retrieve Data Area) 8-9 
CRTICFF (Create Intersystem Communications Function Start Mode (STRMOD) 3-3 

File) 4-2 Start Prestart Jobs (STRPJ) 8-8 
CRTSBSD (Create Subsystem Description) 8-5 Start Service Job (STRSRVJOB) 12-1 
Delete File (DLTF) 4-2 STRMOD (Start Mode) 3-3 
Delete Override (DLTOVR) 4-2 STRPJ (Start Prestart Jobs) 8-8 
Delete Override Device Entry (DLTOVRDEVE) 4-2, 4-7 STRSRVJOB (Start Service Job) 12-1 
Display Active Prestart Jobs (DSPACTPJ) 8-8 summary 4-15 
Display File Description (DSPFD) 4-2 TFRCTL (Transfer Control) 
Display File Field Description (DSPFFD) 4-2 program device entry overrides 4-10 
Display Job (DSPJOB) 12-5 Trace Intersystem Communications Function 
Display Override (DSPOVR) 4-3 (TRCICF) 12-1 

program device entries 4-10 Transfer Control (TFRCTL) 

DLTF (Delete File) 4-2 program device entry overrides 4-10 
DLTOVR (Delete Override) 4-2 TRCICF (Trace Intersystem Communications 
DLTOVRDEVE (Delete Override Device Entry) 4-2, 4-7, Function) 12-1 

4-10 types 4-2 
DSPACTP4 (Display Active Prestart Jobs) 8-8 Vary Configuration (VRYCFG) 3-3, 3-12 
DSPFD (Display File Description) 4-2 VRYCFG (Vary Configuration) 3-3, 3-12 
DSPFFD (Display File Field Description) 4-2 Work with Active Jobs (WRKACTJOB) 12-5 
DSPJOB (Display Job) 12-5 Work with Configuration Status (WRKCFGSTS) B-3 
DSPOVR (Display Override) 4-3, 4-6 Work with Job (WRKJOB) 12-5 

program device entries 4-10 WRKACTJOB (Work with Active Jobs) 12-5 

End Mode (ENDMOD) _ 3-12 WRKCFGSTS (Work with Configuration Status) B-3 
End Prestart Jobs (ENDPJ) 8-8 WRKJOB (Work with Job) 12-5 
End Service Job (ENDSRVJOB) 12-1 Common Programming Interface (CPI) 
ENDMOD (End Mode) 3-12 Communications 2-1 
ENDP4J (End Prestart Jobs) 8-8 communications 
ENDSRVJOB (End Service Job) 12-1 application considerations using ICF file 8-1 
example 4-10 asynchronous 2-2 
file-level attribute type 4-2 configuration 2-4, 3-2 
information display type 4-2 displaying communications status 12-5 
Override Intersystem Communications Function Program ending 3-10, 6-16 

Device Entry (OVRICFDEVE) 4-2 entries 
Override with Intersystem Communications Function File changing 8-5 

(OVRICFF) 4-2, 4-6 default user specification 8-5 
Override with Intersystem Communications Function description 8-5 

Program Device Entry (OVRICFDEVE) 4-7, 4-8 features 2-1 
OVRICFDEVE (Override Intersystem Communications lines 

Function Program Device Entry) 4-2 AS/400 system support 2-3 
OVRICFDEVE (Override with Intersystem Communica- introduction 2-3 

tions Function Program Device Entry) 4-7, 4-8 link 
OVRICFF (Override with Intersystem Communications connecting 3-4 

Function File) 4-2, 4-6 establishing 3-4 
program device entry type 4-2 example 3-7 
Remove Communications Entry (RMVCMNE) 8-5 operating the system 1-1 
Remove Intersystem Communications Function Program operations 

Device Entry (RMVICFDEVE) 4-2, 4-7, 4-10 codes A-1 
Remove Prestart Job Entry (RMVPJE) 8-8 purpose 2-1 
Retrieve Configuration Status (RTVCFGSTS) B-3 processing using DDS keywords 6-1 
Retrieve Data Area (RTVDTAARA) 8-9 program-to-program 3-1 
RMVCMNE (Remove Communications Entry) 8-5 sessions 3-11 
RMVICFDEVE (Remove Intersystem Communications starting 3-4 


Function Program Device Entry) 4-2, 4-7, 4-10 
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communications (continued) 
transactions 3-7 
types 
advanced program-to-program communications 
(APPC) 2-1 
asynchronous 2-2 
binary synchronous communications equivalence link 
(BSCEL) 2-2 
combinations 2-3 
description 3-2 
finance 2-3 
intrasystem 2-2 
introduction 2-1 
retail 2-3 
Systems Network Architecture upline facility 
(SNUF) 2-2 
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Add Communications Entry (ADDCMNE) command 8-5 
ADDCMNE (Add Communications Entry) command 8-5 
adding 8-5 
Change Communications Entry (CHGCMNE) 
command 8-5 
CHGCMNE (Change Communications Entry) 
command 8-5 
Remove Communications Entry (RMVCMNE) 
command 8-5 
RMVCMNE (Remove Communications Entry) 
command 8-5 
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communications transaction 
definition 3-6 
communications type 
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communications type (CMNTYPE) parameter 
use 4-15 
values 4-15 
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RECID keyword 5-9 
configuration 
See also Communications Configuration 
data communications 1-1 
description 2-4, 3-2 
example relationship 3-3 
status B-3 
types 3-2 
varying on 3-3 
VRYCFG description 3-3 
configuring 
communications 3-2 
CONFIRM (confirm) keyword 6-4 
confirm request received 6-19 
considerations 
close 8-3, 8-4 
end-of-session 8-4 
file 8-13 


considerations (continued) 
input 8-3 
language operations A-1 
output 8-2 
programming 
description 8-1 
file overrides 8-13 
file redirection 8-13 
handling program start requests 8-6 
minor 8-1 
remote environment definition 8-5 
remote program start request 8-5 
return codes 8-1 
security 8-12 
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system 8-12 
release 8-3 
control data (CTLDTA) keyword 6-5 
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See also command, CL 
acquire example 3-5 
file transfer support (FTS) example E-32 
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description 4-2 
parameter values 4-5 
Create Subsystem Description (CRTSBSD) 
command 8-5 
CRTCLS (Create Class) command 8-12 
CRTSBSD (Create Subsystem Description) 
command 8-5 
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description 3-9 
example 6-7, 7-6 
how to 6-7, 7-6 
inafile E-1 
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batch transmission example 6-3 
by output operation, example 3-9 
confirm (CONFIRM) 6-4 
control-data (CTLDTA) 6-5 
description 3-9, 5-6 

example 3-1, 6-6 

force-data (FRCDTA) 6-4 
format-name (FMTNAME) 6-4 


function-management-header (FMH) 


inafile E-1 


subdevice-selection (SUBDEV) 6-4 


using DDS keywords 6-3 


variable length data (VARLEN) 6-4 


transfer E-1 
data communications 
configuring your system 1-1 
installing 1-1 
planning 1-1 
data description specifications (DDS) 
description 2-4 
example file 6-20 
functions 4-2 
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allow-write (ALWWRT)_ 6-15 
ALWWRT (allow-write) 6-15 
cancel (CANCEL) 6-10 
cancel-invite (CNLINVITE) 6-16 
CNLINVITE (cancel-invite) 6-16 
confirm (CONFIRM) 6-4 
control-data (CTLDTA) 6-5 
CTLDTA (control-data) 6-5 
defer evoke (DFREVOKE) 6-2 
detach (DETACH) 6-16 
DFREVOKE (defer evoke) 6-2 
end-of-group (ENDGRP) 6-4 
end-of-session (EOS) 6-18 
ENDGRP (end-of-group) 6-4 
EOS (end-of-session) 6-18 
evoke (EVOKE) 6-1 

fail (FAIL) 6-9 
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FMTNAME (format-name) 6-4 
force-data (FRCDTA) 6-4 
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data description specifications (DDS) (continued) 
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format-name (FMTNAME) 6-4 

FRCDTA (force-data) 6-4 
function-management-header (FMH) 6-5 
introduction 6-1 

invite (INVITE) 6-7, 7-6 

map to system-supplied formats 7-21 
negative-response (NEGRSP) 6-11 

NEGRSP (negative-response) 6-11 
prepare-for-commit (PRPCMT) 6-5 

processing 6-1 

processing charts 6-21 

PRPCMT (prepare-for-commit) 6-5 
RCVCANCEL (receive-cancel) 6-19 
RCVCONFIRM (receive confirm) 6-19 
RCVCTLDTA (receive control data) 6-19 
RCVDETACH (receive detach) 6-19 
RCVENDGRP (receive end of group) 6-19 
RCVFAIL (receive fail) 6-19 

RCVFMH (receive-function-management-header) 6-19 
RCVNEGRSP (receive negative response) 6-19 
RCVROLLB (receive rollback) 6-19 
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receive end of group (RCVENDGRP) 6-19 
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receive-take-commit (RCVTKCMT) 6-20 
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record-identification (RECID) 5-8, 6-8 
request-to-write (RQSWRT) 6-13 
respond-to-confirm (RSPCONFIRM) 6-12 
RQSWRT (request-to-write) 6-13 
RSPCONFIRM (respond-to-confirm) 6-12 
security (SECURITY) 6-2 

SUBDEV (subdevice selection) 6-4 

subdevice selection (SUBDEV) 6-4 
synchronization level (SYNLVL) 6-2 

SYNLVL (synchronization level) 6-2 

timer (TIMER) 6-8 

TNSSYNLVL (transaction-synchronization-level) 6-5 
transaction-synchronization-level (TNSSYNLVL) 6-5 
used to send data 6-3 

variable-length data record (VARLEN) 6-4 
VARLEN (variable-length data record) 6-4 


response keywords 6-18 
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data management 
calculating I/O buffers 4-4 
example 3-2 
ICF 3-2 
maximum record length (MAXRCDLEN) 4-4 
data queue (DTAQ) parameter 4-5 
DDS (data description specifications) 
description 2-4 
example file 6-20 
functions 4-2 
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allow-write (ALWWRT) 6-15 
ALWWRT (allow-write) 6-15 
cancel (CANCEL) 6-10 
cancel-invite (CNLINVITE) 6-16 
CNLINVITE (cancel-invite) 6-16 
confirm (CONFIRM) 6-4 
control-data (CTLDTA) 6-5 
CTLDTA (control-data) 6-5 
defer evoke (DFREVOKE) 6-2 
detach (DETACH) 6-16 
DFREVOKE (defer evoke) 6-2 
end-of-group (ENDGRP) 6-4 
end-of-session (EOS) 6-18 
ENDGRP (end-of-group) 6-4 
EOS (end-of-session) 6-18 
evoke (EVOKE) 6-1 
fail (FAIL) 6-9 
FMH (function-management-header) 6-5 
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force-data (FRCDTA) 6-4 
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RCVCANCEL (receive-cancel) 6-19 
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Delete Override Device Entry (DLTOVRDEVE) command 


description 4-7 
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override device entry 4-7 
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example 3-10 
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detail inquiry menu (DTLMNU) 
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errors B-2 
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device entry 
See program device entry 
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Trace ICF (TRCICF) display 12-1 
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description 10-32 
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DLTOVR (Delete Override) command 4-2 
DLTOVRDEVE (Delete Override Device Entry) 
command 4-7 
DSPACTPJ (Display Active Prestart Jobs) command 8-8 
DSPJOB (Display Job) command 12-5 
DSPOVR (Display Override) command 
program device entries 4-10 
DTAQ (data queue) parameter 4-5 
DTLMNU (detail inquiry menu) 
description 11-36 
use 10-35 


E 


EBCDIC character set D-1 
End Mode (ENDMOD) command _ 3-12 
End Prestart Jobs (ENDPJ) command 8-8 
End Service Job (ENDSRVJOB) command 12-1 
end-of-group (ENDGRP) keyword 6-4 
end-of-session (EOS) keyword 6-18 
end-of-session function 
considerations 8-4 
description 6-18 
examples 
C/400 write statement 7-18, 7-20 
release operation 6-18 
system-supplied formats 7-19 
use 7-19 
end-of-transaction operation 7-17 
ENDGRP (end-of-group) keyword 6-4 
ending 
communications 
with a remote system 3-10 
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ending (continued) 
communications (continued) 
with a target system 3-10 
sessions 
communications 6-18 
description 3-11 
end-of-session function 7-19 
release operation 6-18, 7-19 
transactions 3-10, 6-16 
ENDMOD (End Mode) command 3-12 
ENDPJ (End Prestart Jobs) command 8-8 
ENDSRVJOB (End Service Job) command 12-1 
EOS (end-of-session) keyword 6-18 
error 
classification B-1 
exception B-3 
handling 2-5 
messages 
types B-2 
nonpermanent B-3 
permanent B-2 
processing 9-1 
recovery 2-5 
user program detection B-2 
establishing 
session with a requesting program device 3-7 
Ethernet 2-3 
evoke 
parameter list 
format 7-3 
use 7-3 
parameters 3-7 
evoke ($$EVOKNI) system-supplied format 7-2 
evoke (EVOKE) keyword 
compared with system-supplied evoke formats 6-3 
defer evoke 6-2 
format 6-1 
purpose 6-1 
security information 6-2 
use 6-1 
evoke function 
COBOL/400 write statement example 7-3 
description 7-1 
differences between DDS and system-supplied 6-3 
evoke ($$EVOKNI) system-supplied format 7-2 
evoke with detach ($$EVOKET) system-supplied 
format 7-2 
evoke with invite (S$EVOK) system-supplied format 7-2 
example 6-1 
ILE C/400 write statement example 7-3 
parameters 6-1 
RPG/400 send example 7-3 
security information 6-1 
starting remote programs 7-1 
evoke with detach ($$EVOKET) system-supplied format 
description 7-2, 7-17 


evoke with detach ($$EVOKET) system-supplied format file (continued) 


(continued) device 4-1, 4-3 
ending communications 7-17 file members 
evoke with invite ($$EVOK) system-supplied format 7-2 receiving E-1 
example sending E-1 
batch data transfer 10-2 transferring E-1 
batch transmission 6-3 ICF 2-4 
COBOL programming language overrides 8-13 
AS/400 system 10-2 redirection 8-13 
batch data transfer description 10-4, 11-3 support attributes 4-3 
local program 10-2 with OVRICFF 4-6 
file member qualifiers E-9, E-12 writing an ICF file program 5-1 
ILE RPG/400 ICF file to the AS/400 system 11-2 file attribute 
multiple call levels changing an ICF file 4-5 
program device entry override 4-9 communications-type-dependent 4-12 
multiple session description 10-25, 11-25 ICF file 4-3 
multiple sessions overview 10-2, 11-2 overriding an ICF file 4-6 
Override with Intersystem Communications Function file level 
Program Device Entry (OVRICFDEVE) command attribute commands 4-2 
changing running environment 4-9 File Server I/O Processor 
initializing an environment 4-8 definition 2-4 
overriding file transfer support (FTS) 
format selection processing attribute 4-8 AS/400 system 
program device entry retrieving files from System/36 E-9 
overriding remote location name 4-8 sending to System/36 E-6 
protected program device 4-9 compressed data E-1 
RPG/400 programming language definition E-1 
AS/400 system 11-2 example 
batch data transfer description 10-4, 11-3 CL program E-32 
local program 11-3 COBOL/400_ E-23 
securing file member qualifiers E-9, E-12 
program device entry 4-9 ILE C/400 E-16 
RPG/400_ E-28 
F messages E-34 
multiple communication-type support E-2 
fail ($$FAIL) system-supplied format parameter list E-3 
C/400 write statement example 7-9 qualifiers E-3 
COBOL/400 write statement example 7-9 retrieving from System/36 E-2 
description 7-8 retrieving library member from System/36 E-12 
example 7-8 sending file members E-2 
RPG/400 output specification example 7-9 subsystems using E-1 
fail (FAIL) keyword transferring files to and from an AS/400 system E-3 
format 6-9 finance communications 
receiving example 6-9 controllers 2-3 
sending example operation 6-10 definition 2-3 
use 6-9 ICF-supported communications 2-3 
fail function non-ICF communications 2-3 
C/400 statement example 7-9 X.25 support 2-3 
COBOL statement example 7-9 Financial Branch System Services (FBSS) controller 2-3 
RPG/400 statement example 7-9 FMH (function management header) keyword 6-5 
FBSS (Financial Branch System Services) controller 2-3 FMTNAME (format name) keyword 6-4 
features FMTSLT (format select) parameter 
communications 2-1 description 5-8 
feedback area C-1 determining record format 5-14 
file use 4-14 
changing an ICF file 4-5 values 4-14 
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force data (FRCDTA) keyword 6-4 
format name (FMTNAME) keyword 6-4 
format select (FMTSLT) parameter 
description 5-8 
determining record format 5-14 
use 4-14 
values 4-14 
format selection processing 
remote (RMTFMT) 5-8 
summary 5-8 
format, system-supplied 
$$CANL (cancel with invite) 7-10 
$$CANLNI (cancel) 
sending error signal example 7-10 
$$CNLINV (cancel invite) 
COBOL/400 WRITE statement example 7-16 
description 7-16 
example 7-16 
ILE C/400 write statement example 7-16 
RPG/400 example 7-16 
$$EVOK (evoke with invite) 7-2 
$$EVOKET (evoke with detach) 
description 7-17 
ending communications 7-17 
$$EVOKNI (evoke) 7-2 
$$FAIL (fail) 
C/400 write statement example 7-9 
COBOL/400 write statement example 7-9 
description 7-8 
example 7-8 
RPG/400 output specification example 7-9 
$$NRSPNI (negative-response) 
description 7-11 
sending error condition example 7-11 
$$POSRSP (positive-response) 7-13, A-6 
$$RCD (request-to-write-with-invite) 7-6 
$$SEND (send with invite) 7-4, 7-6 
$$SENDE (send with end-of-group) 7-4, 7-11 
$$SENDET (send with detach) 
COBOL/400 program 7-18 
description 7-4, 7-17 
ending communications 7-17 
ILE C/400 example 7-18 
RPG/400 example 7-18 
transaction end example 7-17 
$$SENDFM (send with function-management-header and 
invite) 7-4, 7-6 
$$SENDNF (send with 
function-management-header) 7-4 
$$SENDNI (send) 7-4 
$$TIMER (timer) 
C/400 example 7-7 
COBOL/400 example 7-7 
format 7-7 
output field format 7-7 
purpose 7-7 
RPG/400 example 7-7 
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format, system-supplied (continued) 


$$TIMER (timer) (continued) 
use 7-7 
cancel ($$CANLNI) 
sending error signal example 7-10 
cancel invite ($$CNLINV) 
COBOL/400 WRITE statement example 7-16 
description 7-16 
example 7-16 
ILE C/400 write statement example 7-16 
RPG/400 example 7-16 
cancel with invite (S$CANL) 7-10 
evoke ($$EVOKNI) 7-2 
evoke with detach ($$EVOKET) 
description 7-2, 7-17 
ending communications 7-17 
evoke with invite ($$EVOK) 7-2 
fail (S$FAIL) 
C/400 write statement example 7-9 
COBOL/400 write statement example 7-9 
description 7-8 
example 7-8 
RPG/400 output specification example 7-9 
negative-response ($$NRSPNI) 
description 7-11 
sending error condition example 7-11 
negative-response-with-invite ($$NRSP) 
description 7-6, 7-11 
output buffer requirements 7-12 
positive-response (6$POSRSP) 7-13, A-6 
request-to-write-with-invite (S$RCD) 7-6 
send ($$SENDNI) 7-4 
send with detach ($$SENDET) 
COBOL/400 program 7-18 
description 7-4, 7-17 
ending communications 7-17 
ILE C/400 example 7-18 
RPG/400 example 7-18 
transaction end example 7-17 
send with end-of-group ($$SENDE) 7-4, 7-11 
send with function-management-header 
($$SENDNF) 7-4 
send with function-management-header and invite 
($$SENDFM) 7-4, 7-6 
send with invite (S$SEND) 7-4, 7-6 
timer ($$TIMER) 
C/400 example 7-7 
COBOL/400 example 7-7 
format 7-7 
output field format 7-7 
purpose 7-7 
RPG/400 example 7-7 
use 7-7 


FORTRAN/400 language support 4-7 
FRCDTA (force data) keyword 6-4 


FTS (file transfer support) 
AS/400 system 
retrieving files from System/36 E-9 
sending to System/36 E-6 
compressed data _ E-1 
definition E-1 
example 
CL program E-32 
COBOL/400_ E-23 
file member qualifiers E-9, E-12 
ILE C/400 E-16 
RPG/400_ E-28 
messages E-34 
multiple communication-type support E-2 
parameter list E-3 
qualifiers E-3 
retrieving from System/36 E-2 
retrieving library member from System/36 E-12 
sending file members E-2 
subsystems using E-1 
transferring files to and from an AS/400 system E-3 
function 
allow-write (ALWWRT) 6-15 
function management header (FMH) keyword 6-5 


G 


get operation 
See read operation 
get-attributes operation 
language operations A-1 
status information fields 5-3 
use 5-3 


H 


high-level language (HLL) 
example program 2-5 
languages supported 2-5 

HLL (high-level language) 
example program 2-5 
languages supported 2-5 


V/O feedback area 
common C-3 
description 5-6 
file-dependent C-3 
types C-3 
ICF (intersystem communications function) 
acquire, description 3-5 
attributes 4-12 
commands 


Add Intersystem Communications Function Program 


Device Entry (ADDICFDEVE) 4-2 
ADDICFDEVE (Add Intersystem Communications 
Function Program Device Entry) 4-2 


ICF (intersystem communications function) (continued) 


commands (continued) 
Change Intersystem Communications Function File 
(CHGICFF) 4-2 
Change Intersystem Communications Function 
Program Device Entry (CHGICFDEVE) 4-2 
CHGICFDEVE (Change Intersystem Communications 
Function Program Device Entry) 4-2 
CHGICFF (Change Intersystem Communications Func- 
tion File) 4-2 
Create Intersystem Communications Function File 
(CRTICFF) 4-2 
CRTICFF (Create Intersystem Communications Func- 
tion File) 4-2 
Delete File (DLTF) 4-2 
Delete Override (DLTOVR) 4-2 
Delete Override Device Entry (DLTOVRDEVE) 4-2 
Display File Description (DSPFD) 4-2 
Display File Field Description (DSPFFD) 4-2 
Display Override (DSPOVR) 4-3 
DLTF (Delete File) 4-2 
DLTOVR (Delete Override) 4-2 
DLTOVRDEVE (Delete Override Device Entry) 4-2 
DSPFD (Display File Description) 4-2 
DSPFFD (Display File Field Description) 4-2 
DSPOVR (Display Override) 4-3 
file-level attribute type 4-2 
information display type 4-2 
Override Intersystem Communications Function 
Program Device Entry (OVRICFDEVE) 4-2 
Override with Intersystem Communications Function 
File (OVRICFF) 4-2 
OVRICFDEVE (Override Intersystem Communications 
Function Program Device Entry) 4-2 
OVRICFF (Override with Intersystem Communications 
Function File) 4-2 
program device entry type 4-2 
Remove Intersystem Communications Function 
Program Device Entry (RMVICFDEVE) 4-2 
RMVICFDEVE (Remove Intersystem Communications 
Function Program Device Entry) 4-2 
summary 4-15 
types 4-2 
communications operations 3-1 
communications types 
introduction 2-1 
purpose 2-1 
support 3-2 
creating a file 6-20 
data management, definition 3-2 
defining program devices to 4-7 
definition 3-1 
description 3-1 
example configuration 3-3 
file 
attributes 4-3 
changing 4-5 
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ICF (intersystem communications function) (continued) 
file (continued) 
closing 5-17 
commands 4-2 
configuration relationship 3-3 
creating 4-2, 6-20 
defining record formats 4-3 
definition 3-3 
description 2-4, 4-1 
device 4-1 
maximum record length 4-4 
opening 4-3, 5-1 
overriding 4-6 
overview example 4-1 
QICDMF 4-2 
requesting device input/output following an 
acquire 8-1 
support attributes 4-3 
target program input/output following an acquire 8-1 
using 5-1 
file-level attribute type 4-2 
general description 1-1 
maximum number of program devices 4-3 
mode name 5-7 
negative response error data 5-6 
opening 5-1 
operations and functions 
acquire 5-2 
allow-write 6-15 
cancel 6-10, 7-10 
cancel-invite 6-16, 7-16 
confirm 6-4 
detach 3-10 
end-of-group 6-4 
end-of-session 3-11 
end-of-session function 7-19 
ending a session (detach function) 7-17 
ending a transaction (detach keyword) 6-16 
evoke, general description 6-1, 7-2 
fail 6-9, 7-8 
force-data 6-4 
format-name_ 6-4 
function-management header 6-5 
how to use 6-1 
invite 6-7, 7-6 
negative-response 6-11, 7-11 
positive-response 7-13 
read 6-7, 7-6 
read-from-invited-program-devices 6-7, 7-6 
release 5-16 
request-to-write 6-13, 7-13 
respond-to-confirm 6-12 
select record format 6-8 
subdevice-selection 6-4 
summary chart 6-21, 7-19 
timer 6-8, 7-7 
variable-length 6-4 
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ICF (intersystem communications function) (continued) 
operations and functions (continued) 
write 6-3, 7-4 
other communication types 2-3 
program start requests 3-16 
record formats 4-3 
remote format name 5-6 
remotely started sessions 3-16 
return code 5-6 
safe indicator 5-7 
using 5-1 
write request indication 5-6 
writing a program 5-1 
ICF device entry 
adding 4-7, 4-10 
ILE COBOL/400 programming language 
See COBOL/400 programming language 
ILE RPG/400 programming language 
See RPG/400 programming language 
IMS (Information Management System) 2-2 
Information Management System (IMS) 2-2 
input 
considerations 8-3 
Operations 6-7, 7-6 
input/output feedback area 
See I/O feedback area 
installing 
data communications 1-1 
integrated services digital network (ISDN) 
definition 2-4 
International Telegraph and Telephone Consultative 
Committee (CCITT) 
recommendation 
X.28 2-2 
X.29 2-2 
X.3 2-2 
intersystem communications function (ICF) 
acquire, description 3-5 
attributes 4-12 
closing 5-17 
commands 
Add Intersystem Communications Function Program 
Device Entry (ADDICFDEVE) 4-2 
ADDICFDEVE (Add Intersystem Communications 
Function Program Device Entry) 4-2 
Change Intersystem Communications Function File 
(CHGICFF) 4-2 
Change Intersystem Communications Function 
Program Device Entry (CHGICFDEVE) 4-2 
CHGICFDEVE (Change Intersystem Communications 
Function Program Device Entry) 4-2 
CHGICFF (Change Intersystem Communications Func- 
tion File) 4-2 
Create Intersystem Communications Function File 
(CRTICFF) 4-2 
CRTICFF (Create Intersystem Communications Func- 
tion File) 4-2 


intersystem communications function (ICF) (continued) 
commands (continued) 
Delete File (DLTF) 4-2 
Delete Override (DLTOVR) 4-2 
Delete Override Device Entry (DLTOVRDEVE) 4-2 
Display File Description (DSPFD) 4-2 
Display File Field Description (DSPFFD) 4-2 
Display Override (DSPOVR) 4-3 
DLTF (Delete File) 4-2 
DLTOVR (Delete Override) 4-2 
DLTOVRDEVE (Delete Override Device Entry) 4-2 
DSPFD (Display File Description) 4-2 
DSPFFD (Display File Field Description) 4-2 
DSPOVR (Display Override) 4-3 
file-level attribute type 4-2 
information display type 4-2 
Override Intersystem Communications Function 
Program Device Entry (OVRICFDEVE) 4-2 
Override with Intersystem Communications Function 
File (OVRICFF) 4-2 
OVRICFDEVE (Override Intersystem Communications 
Function Program Device Entry) 4-2 
OVRICFF (Override with Intersystem Communications 
Function File) 4-2 
program device entry type 4-2 
Remove Intersystem Communications Function 
Program Device Entry (RMVICFDEVE) 4-2 
RMVICFDEVE (Remove Intersystem Communications 
Function Program Device Entry) 4-2 
summary 4-15 
types 4-2 
communications operations 3-1 
communications types 
introduction 2-1 
purpose 2-1 
support 3-2 
creating a file 6-20 
data management, definition 3-2 
defining program devices to 4-7 
definition 1-1, 3-1 
description 3-1, 4-1 
end-of-session 6-18 
evoke example 6-1 
example configuration 3-3 
file 
attributes 4-3 
changing 4-5 
closing 5-17 
commands 4-2 
configuration relationship 3-3 
creating 4-2, 6-20 
defining record formats 4-3 
definition 3-3 
description 2-4, 4-1 
device 4-1,4-2 
maximum record length 4-4 
opening 4-3, 5-1 


intersystem communications function (ICF) (continued) 


file (continued) 
overriding 4-6 
overview example 4-1 
QICDMF 4-2 
requesting device input/output following an 
acquire 8-1 
support attributes 4-3 
target program input/output following an acquire 8-1 
using 5-1 
file-level attribute type 4-2 
general description 1-1 
maximum number of program devices 4-3 
mode name _ 5-7 
negative response error data 5-6 
operations and functions 
acquire 5-2 
allow-write 6-15 
cancel 6-10, 7-10 
cancel-invite 6-16, 7-16 
confirm 6-4 
detach 3-10 
end-of-group 6-4 
end-of-session 3-11 
end-of-session function 7-19 
ending a session (detach function) 7-17 
ending a transaction (detach keyword) 6-16 
evoke, general description 6-1, 7-2 
fail 6-9, 7-8 
force-data 6-4 
format-name 6-4 
function-management header 6-5 
how to use 6-1 
invite 6-7, 7-6 
negative-response 6-11, 7-11 
positive-response 7-13 
read 6-7, 7-6 
read-from-invited-program-devices 6-7, 7-6 
release 5-16 
request-to-write 6-13, 7-13 
respond-to-confirm 6-12 
select record format 6-8 
subdevice-selection 6-4 
summary chart 6-21, 7-19 
timer 6-8, 7-7 
variable-length 6-4 
write 6-3, 7-4 
other communication types 2-3 
program start requests 3-16 
record formats 4-3 
remote format name 5-6 
remotely started sessions 3-16 
return code 5-6 
safe indicator 5-7 
using 5-1 
write request indication 5-6 
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intersystem communications function (ICF) (continued) keyword, DDS (continued) 


writing a program 5-1 problem notification (continued) 
intersystem communications function (ICF) program fail (FAIL) 6-9 
device entry negative-response (NEGRSP) 6-11 
adding 4-7 PRPCMT (prepare-for-commit) 6-5 
removing 4-10 RCVCANCEL (receive-cancel) 6-19 
intrasystem communications RCVCONFIRM (receive confirm) 6-19 
definition 2-2 RCVCTLDTA (receive control data) 6-19 
invite (INVITE) keyword 6-7 RCVDETACH (receive detach) 6-19 
invite function RCVENDGRP (receive end of group) 6-19 
description 6-7, 7-6 RCVFAIL (receive fail) 6-19 
example 5-10 RCVFMH (receive-function-management-header) 6-19 
inviting RCVNEGRSP (receive negative response) 6-19 
program device 5-7 RCVROLLB (receive rollback) 6-19 
ISDN (integrated services digital network) RCVTKCMT (receive-take-commit) 6-20 
definition 2-4 RCVTRNRND (receive turnaround) 6-19 
item inquiry menu (ITMMNU) 10-35 receive confirm (RCVCONFIRM) 6-19 
item inquiry screen 2 (ITMSC2) 11-36 receive control data (RCVCTLDTA) 6-19 
item inquiry screen 3 (ITMSC3) 11-36 receive detach (RCVDETACH) 6-19 
receive end of group (RCVENDGRP) 6-19 
J receive fail (RCVFAIL) 6-19 
receive negative response (RCVNEGRSP) 6-19 
job ended signal 5-13 receive rollback (RCVROLLB) 6-19 
receive turnaround (RCVTRNRND) 6-19 
K receive-cancel (RCVCANCEL) 6-19 


receive-function-management-header (RCVFMH) 6-19 
receive-take-commit (RCVTKCMT) 6-20 
receiving data 

invite (INVITE) 6-7 

record-identification (RECID) 6-8 

timer (TIMER) 6-8 
RECID (record-identification) 6-8 
record-identification (RECID) 6-8 
request-to-write (RQSWRT) 6-13 
respond-to-confirm (RSPCONFIRM) 6-12 
RQSWRT (request-to-write) 6-13 
RSPCONFIRM (respond-to-confirm) 6-12 
security (SECURITY) 6-2 
SUBDEV (subdevice selection) 6-4 
subdevice selection (SUBDEV) 6-4 
synchronization level (SYNLVL) 6-2 
SYNLVL (synchronization level) 6-2 
timer (TIMER) 6-8 
TNSSYNLVL (transaction-synchronization-level) 6-5 
transaction-synchronization-level (TNSSYNLVL) 6-5 
variable-length data record (VARLEN) 6-4 
VARLEN (variable-length data record) 6-4 


keyword processing charts 6-21 

keyword, DDS 
allow-write (ALWWRT) 6-15 
ALWWRT (allow-write) 6-15 
cancel (CANCEL) 6-10 
cancel-invite (CNLINVITE) 6-16 
CNLINVITE (cancel-invite) 6-16 
confirm (CONFIRM) 6-4 
control-data (CTLDTA) 6-5 
CTLDTA (control-data) 6-5 
defer evoke (DFREVOKE) 6-2 
detach (DETACH) 6-16 
DFREVOKE (defer evoke) 6-2 
end-of-group (ENDGRP) 6-4 
end-of-session (EOS) 6-18 
ENDGRP (end-of-group) 6-4 
EOS (end-of-session) 6-18 
evoke (EVOKE) 6-1 
fail (FAIL) 6-9 
FMH (function-management-header) 6-5 
FMTNAME (format-name) 6-4 
force-data (FRCDTA) 6-4 
format-name (FMTNAME) 6-4 


FRCDTA (force-data) 6-4 L 

function-management-header (FMH) 6-5 LAN (local area network) 

invite (INVITE) 6-7 Ethernet 2-3 
negative-response (NEGRSP) 6-11 token-ring 2-3 

NEGRSP (negative-response) 6-11 language operations supported 
prepare-for-commit (PRPCMT) 6-5 by ICF A-1 


problem notification 
cancel (CANCEL) 6-10 
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LCLLOCNAME (local location name) parameter 4-11 
library member E-12 
load library member (QS36LOD) E-2 
local area network (LAN) 
Ethernet 2-3 
token-ring 2-3 
local location name (LCLLOCNAME) parameter 4-11 
local system 5-18 
locally started sessions 3-14 
logical unit type 6.2 (LU 6.2) 2-1 
LU 6.2 (logical unit type) 2-1 


major code 
00 B-4 
02 B-6 
03 B-10 
04 B-11 
08-11 B-12 
34 B-12 
80 B-13 
81 B-14 
82 B-17 
83 B-20 
major return code 8-1 
maximum file wait time (WAITFILE) parameter 4-5 
maximum program devices (MAXPGMDEV) 
parameter 4-4 
maximum record length (MAXRCDLEN) parameter 4-3, 
4-4 
maximum record wait time (WAITRCD) parameter 
description 4-5 


difference 

from TIMER keyword 6-8 
use 4-5 
values 

general 4-5 


using read-from-invited-program-devices 4-5 
without using read-from-invited-program-devices 4-5 
maximum wait interval 5-12 
MAXPGMDEV (maximum program devices) 
parameter 4-4 
MAXRCDLEN (maximum record length) parameter 4-3, 
4-4 
message identifier B-2 
message type B-2 
message, file transfer E-34 
minor return code 8-1 
mode (MODE) parameter 4-11 
MPTN (Multiprotocol Transport Networking) 
architecture 2-2 
multiple 
sessions 3-13 
transactions 3-12 


multiple call level 
program device entry example 4-9 
multiple-session inquiry example 
description for COBOL/400 program 10-25 
description for ILE C/400 program 9-1 
Multiprotocol Transport Networking (MPTN) 
architecture 2-2 


N 


negative-response ($$NRSPNI) system-supplied format 

description 7-11 

sending error condition example 7-11 
negative-response (NEGRSP) keyword 6-11 
negative-response function 

COBOL/400 program 7-12 

ILE C/400 program 7-12 

RPG/400 example 7-12 
negative-response-with-invite ($$NRSP) system-supplied 

format 

description 7-6, 7-11 

output buffer requirements 7-12 
NEGRSP (negative-response) keyword 6-11 
nested call 

program device entry example 4-9 
network 

Ethernet 2-3 

token-ring 2-3 
nonintersystem communications 

combinations of communications types 2-3 

remote work stations 2-3 

running on the AS/400 system 2-3 
number of seconds value 4-5 


O 


open feedback area 5-1 
Open operation 
language operations A-1 
programming considerations 8-2 
opening the ICF file 3-4 
operation 
See CL Reference 
See System Operation 
operations and functions 
See also acquire operation 
See also close operation 
allow-write (ALWWRT) 6-15 
cancel 6-10 
detach 
description 3-10 
example 3-10 
return code checking 3-10 
end-of-session 3-11 
evoke 
COBOL/400 write statement example 7-3 
ILE C/400 write statement example 7-3 
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operations and functions (continued) 
evoke (continued) 
parameters 3-7 
RPG/400 send example 7-3 
use with DDS keywords 6-1 
get 7-6 
ICF 3-1 
invite 6-7, 7-6 
read 6-7 
read-from-invited-program-devices 6-7, 7-6 
request-to-write (RQSWRT) 6-13 
output considerations 8-2 
output operation 
COBOL/400 send data example 7-5 
description 6-3 
ILE C/400 send data example 7-5 
RPG/400 send data example 7-6 
sending data (COBOL/400 programming language) 7-4 
override 
device entry 
deleting 4-7 
format selection processing attribute 
example 4-8 
multiple call levels 
program device entries 4-9 
program device entries 
considerations 4-8 
deleting 4-10 
description 4-7 
example 4-9 
remote location name 4-8 
remote location name and session attributes 4-8 
session attributes 4-8 
Override with Intersystem Communications Function 
Program Device Entry (OVRICFDEVE) command 
description 4-7 
example 4-8 
overriding 
program device entries 
applying from multiple call levels 4-9 
considerations 4-8 
deleting 4-10 
description 4-7 
overriding 4-9 
remote location name and session attributes 4-8 
OVRICFDEVE (Override with Intersystem Communica- 
tions Function Program Device Entry) command 4-7 
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packet assembler/disassembler (PAD) 2-2 
packet-switching data network (PSDN) 2-2 
PAD (packet assembler/disassembler) 2-2 
parameter 
ACQPGMDEV (program device to acquire) 4-3, 4-7 
CMNTYPE (communications type) 4-15 
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parameter (continued) 
communications type (CMNTYPE) 4-15 
data queue (DTAQ) 4-5 
DEV (device description) 4-11 
device description (DEV) 4-11 
DTAQ (data queue) 4-5 
evoke 3-7 
evoke function 6-1 
FMTSLT (format select) 4-14 
format select (FMTSLT) 4-14 
LCLLOCNAME (local location name) 4-11 
local location name (LCLLOCNAME) 4-11 
maximum file wait time (WAITFILE) 4-5 
maximum program devices (MAXPGMDEV) 4-4 
maximum record length (MAXRCDLEN) 4-3, 4-4 
maximum record wait time (WAITRCD) 4-5 
MAXPGMDEV (maximum program devices) 4-4 
MAXRCDLEN (maximum record length) 4-3, 4-4 
MODE (mode) 4-11 
NONE 4-3 
PGMDEV (program device name) 3-5 
PGMDEV (program device) 4-7, 4-10 
program device (PGMDEV) 4-7 
program device to acquire (ACQPGMDEV) 4-3 
PURGE (purge) 8-12 
remote location name (RMTLOCNAME) 4-11 
remote network identifier (RMTNETID) 4-11 
RMTLOCNAME (remote location name) 4-11 
RMTNETID (remote network identifier) 4-11 
SECURE (secure from override) 4-15 
secure from override (SECURE) 4-15 
sent to the started program 3-16 
session attributes 4-8 
WAITFILE (maximum file wait time) 4-5 
WAITRCD (maximum record wait time) 4-5 
parameter list 
evoke 7-3 
file transfer E-3 
format 7-3 
permanent 
definition 4-7 
PGMDEV (program device) parameter 4-7, 4-10 
planning, communications 
data communications 1-1 
positive-response ($$POSRSP) system-supplied 
format 7-13, A-6 
prepare-for-commit (PRPCMT) keyword 
description 6-5 
prestart job entry 
application considerations 8-8 
commands 
Add Prestart Job Entry (ADDPJE) 8-8 
ADDPJE (Add Prestart Job Entry) 8-8 
Change Prestart Job (CHGPJ) 8-8 
Change Prestart Job Entry (CHGPJE) 8-8 
CHGPJ (Change Prestart Job) 8-8 
CHGPUJE (Change Prestart Job Entry) 8-8 


prestart job entry (continued) 
commands (continued) 
Display Active Prestart Jobs (DSPACTPJ) 8-8 
DSPACTP4 (Display Active Prestart Jobs) 8-8 
End Prestart Jobs (ENDPJ) 8-8 
ENDP4J (End Prestart Jobs) 8-8 
Remove Prestart Job Entry (RMVPJE) 8-8 
Retrieve Data Area (RTVDTAARA) 8-9 
RMVPJE (Remove Prestart Job Entry) 8-8 
RTVDTAARA (Retrieve Data Area) 8-9 
Start Prestart Jobs (STRPJ) 8-8 
STRPJ (Start Prestart Jobs) 8-8 
description 8-8 
program initialization parameters 8-9 
security considerations 8-9 
problem analysis 
error detection 12-1 
problem notification 
formats 7-8 
functions 6-9 
procedure library member (QS36PRC) E-2 
processing 
override 
example 4-6 
methods 4-6 
release operation 5-16 
using DDS keywords 6-1 
program 
application definition 3-2 
application started by AS/400 system 3-4 
at a remote system 3-6, 3-16 
evoke functions 7-1 
link with target program, example 3-9 
parameters sent to started program 3-16 
start requests 3-16 
starting 
description 3-4 
on the remote system 6-1 
remote programs 7-1 
starts remote session, example 3-14 
program device 
acquire example 4-5 
acquiring 
description 5-2 
source program device 5-2 
target program device 5-3 
when file is open 4-3 
canceling an invite 5-15 
defining 
system-supplied entries 7-1 
to an ICF file 4-7 
definition 4-1 
definition list 5-3, C-2 
determining 
maximum number 4-4 
which has data 5-14 


program device (continued) 
entries 4-1 
error from one 5-14 


FORTRAN/400 language does not support names 4-7 


get attributes 5-3 
invited signal 5-13 
inviting 5-7 
levels 4-7 
mapping to communications configurations 4-10 
obtaining device information 5-3 
permanent definition 4-7 
program device entry commands 4-2 
program device name 4-4 
read from 
description 5-10 
example 5-10 
one device 5-14 
time out 5-13 
reading from invited 5-10 
releasing 5-16 
specifying 4-1 
temporary definition 4-7 
writing then reading from one 5-15 
writing to 5-7 
program device (PGMDEV) parameter 3-5, 4-7 
program device entry 
change running environment 4-9 
changing remote location and attributes of 4-9 
commands to define 4-7 
functions 4-7 
initializing environment 4-8 
multiple 4-7 
multiple call level example 4-9 
overrides 
considerations 4-8 
description 4-7 
displaying 4-10 
protecting example 4-9 
remote location name 
example 4-8 
securing 4-9 


program device to acquire (ACQPGMDEV) parameter 


description 4-7 
open operation 5-1 
use 4-3 
values 4-3 
program start request 
definition 3-4 
description of failures (message CPF1269) B-23 
failed B-23 
introduction 3-4 
prestart jobs 8-8 
reason codes_ B-23 
starts a session 3-16 
programming considerations 
acquire 8-2 
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programming considerations (continued) 
applications using ICF file 
COBOL/400 language 10-1 
ILE C/400 language 9-1 
RPG/400 language 11-1 
close 8-4 
communications using ICF file 8-1 
defining environment 8-5 
description 8-1 
end-of-session 8-4 
files 
overrides 8-13 
redirection 8-13 
handling program start requests 8-6 
input 8-3 
major codes 8-1 
minor codes 8-1 
open 8-2 
output 8-2 
prestarting jobs 8-8 
release 8-3 
remote environment definition 8-5 
remote program start request 8-5 
return codes 8-1 
security 8-12 
subsystem creation 8-5 
system 8-12 
programming language 
ILE COBOL/400 summary charts 
communications operations A-1 
operation codes A-1 
ILE RPG/400 summary charts 
communications operations A-1 
operation codes A-1 
PRPCMTT (prepare-for-commit) keyword 
description 6-5 
PSDN (packet-switching data network) 2-2 
PURGE (purge) parameter 8-12 
put operation 
See write operation 
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QBASE subsystem 8-5 
QCMN subsystem 8-5 
QICDMF file 
characteristics 7-1 
purpose 4-2 
use 7-1 
QS36LOD (load library member) E-2 
QS36PRC (procedure library member) E-2 
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RCVCANCEL (receive-cancel) keyword 6-19 
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RCVCONFIRM (receive-confirm) keyword 6-19 
RCVCTLDTA (receive-control-data) keyword 6-19 
RCVDETACH (receive-detach) keyword 6-19 
RCVENDGRP (receive-end-of-group) keyword 6-19 
RCVFAIL (receive-fail) keyword 6-19 
RCVFMH (receive-function-management-header) 
keyword 6-19 

RCVNEGRSP (receive-negative-response) keyword 6-19 
RCVROLLB (receive-rollback) keyword 6-19 
RCVTKCIMT (receive-take-commit) keyword 6-20 
RCVTRNRND (receive-turnaround) keyword 6-19 
read operation 

description 6-7 

example 5-15 

language operations A-1 
read-from-invited-program-devices operation 

data available 5-13 

example 6-7, 7-6 

language operations A-1 

Operations 6-7 

responses 5-13 

using 5-10 
read-under-format (RUF) support 12-4 
reason codes (for failed program start requests) B-23 
receive-cancel (RCVCANCEL) keyword 6-19 
receive-confirm (RCVCONFIRM) keyword 6-19 
receive-control-data (RCVCTLDTA) keyword 6-19 
receive-detach (RCVDETACH) keyword 6-19 
receive-end-of-group (RCVENDGRP) keyword 6-19 
receive-fail (RCVFAIL) keyword 6-19 
receive-function-management-header (RCVFMH) 

keyword 6-19 

receive-negative-response (RCVNEGRSP) keyword 6-19 
receive-rollback (RCVROLLB) keyword 6-19 
receive-take-commit (RCVTKCMT) keyword 6-20 
receive-turnaround (RCVTRNRND) keyword 6-19 
receiving 

cancel signals 6-19 

data 3-9 

fail signal 6-19 

negative response 6-19 
RECID (record identification) keyword 

compare values 5-9, 6-9 

duplicate compare values 6-9 

format 5-8, 6-8 

use 5-8, 6-8 
record 

actual length 5-6 

blocked record count 5-6 

determining 

format of returned 5-14 
maximum length 4-4 

format name 5-6 

length 5-6 

selecting formats 5-8 

spooled trace 12-3 


record identification (RECID) keyword 
compare values 5-9, 6-9 
duplicate compare values 6-9 
format 5-8, 6-8 
use 5-8, 6-8 
release considerations 8-3 
release operation 
considerations 8-3 
example 3-11, 6-18, 7-19 
language operations A-1 
processing 5-16 
releasing 
program device 5-16 
remote format (*“RMTFMT) value 5-9 
remote location and attributes, changing 4-9 
remote location name (RMTLOCNAME) parameter 4-11 
remote location name and session attributes 4-8 
remote network identifier (RMTNETID) parameter 4-11 
remote program 
considerations 8-5 
procedure start request 3-7 
start request 3-6 
remote system 
program start example 3-7 
started by application program, example 3-14 
starting a program 3-7 
target program 5-19 
remote work station 2-3 
remotely started session 3-16 
Remove Communications Entry (RMVCMNE) 
command 8-5 
Remove Intersystem Communications Function Program 
Device Entry (RMVICFDEVE) command 4-10 
description 4-2 
use 4-2, 4-7 
Remove Prestart Job Entry (RMVPJE) command 8-8 
removing 
intersystem communications function program device 
entry 4-10 
request to write with invite ($$RCD) system-supplied 
format 7-6, 7-13 
request-to-write (RQSWRT) keyword 6-13 
request-to-write function 7-13 
requesting device 
description 3-7 
input/output following an acquire (ICF file) 8-1 
requesting program device 
definition 3-7 
respond-to-confirm (RSPCONFIRM) keyword 6-12 
response indicator 
receive-cancel (RCVCANCEL) 6-19 
receive-confirm (RCVCONFIRM) 6-19 
receive-control-data (RCVCTLDTA) 6-19 
receive-detach (RCVDETACH) 6-19 
receive-end-of-group (RCVENDGRP) 6-19 
receive-fail (RCVFAIL) 6-19 


response indicator (continued) 
receive-function-management-header (RCVFMH) 6-19 
receive-negative-response (RCVNEGRSP) 6-19 
receive-rollback (RCVROLLB) 6-19 
receive-take-commit (RCVTKCMT) 6-20 
receive-turnaround (RCVTRNRND) 6-19 
response indicator keyword 6-18 
retail communications 
controllers 2-3 
definition 2-3 
X.25 support 2-3 
Retail Industry Programming Support Services 
(RIPSS) 2-3 
Retrieve Configuration Status (RTVCFGSTS) 
command _ B-3 
Retrieve Data Area (RTVDTAARA) command 8-9 
retrieving 
files from System/36 E-9 
from System/36 E-2 
library member E-12 
return code 
checking for 
detach 3-10 
end of transaction 6-19 
Operation status 5-7 
major 
description 2-5, 8-1 
types 8-1 
minor 
description 2-5, 8-1 
types 8-1 
programming considerations 8-1 
purpose 2-1 
RIPSS (Retail Industry Programming Support 
Services) 2-3 
RMTLOCNAME (remote location name) parameter 4-11 
RMTNETID (remote network identifier) parameter 4-11 
RMVCMNE (Remove Communications Entry) 
command 8-5 
RMVICFDEVE (Remove Intersystem Communications 
Function Program Device Entry) command 4-10 
description 4-2 
use 4-2, 4-7 
RMVPJE (Remove Prestart Job Entry) command 8-8 
RPG/400 programming language 
display file 11-25, 11-33 
error handling 11-1 
examples 
file transfer support (FTS) E-28 
multiple-session 11-25 
negative-response output specifications 7-12 
set timer function 7-7 
source program 11-5 
target program 11-16 
feedback areas 11-2 
file transfer support (FTS) 
example E-28 
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RPG/400 programming language (continued) 
file transfer support (FTS) (continued) 
parameter list E-3 
qualifiers E-3 
interface 11-1 
introduction 11-1 
multiple-session 
source program 11-33 
target program 11-65 
request-to-write 7-15 
use in FTS_ E-1 
RQSWRT (request-to-write) keyword 6-13 
RSPCONFIRM (respond-to-confirm) keyword 6-12 
RTVCFGSTS (Retrieve Configuration Status) 
command B-3 
RTVDTAARA (Retrieve Data Area) command 8-9 
RUF (read-under-format) support 12-4 
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SDLC (synchronous data link control) 
definition 2-3 
SECURE (secure from override) parameter 4-15 
secure from override (SECURE) parameter 4-15 
securing 
program device entry example 4-9 
security 
defer evoke (DFREVOKE) keyword 6-2 
DFREVOKE (defer evoke) keyword 6-2 
error handling 2-5 
evoke 6-1 
evoke, deferred 6-2 
general description 2-5 
prestart jobs 8-9 
SECURITY keyword 6-2 
sending to aremote system 6-2 
security (SECURITY) keyword 6-2 
selecting 
record formats 5-8 
send ($$SENDNI) system-supplied format 7-4 
send function management header then invite 
($$SENDFM) system-supplied format 7-4 
send with detach ($$SENDET) system-supplied format 
description 7-4, 7-17 
ending communications 7-17 
examples 
COBOL/400 program 7-18 
ILE C/400 example 7-18 
RPG/400 example 7-18 
transaction end 7-17 
send with end of group ($$SENDE) system-supplied 
format 7-4, 7-11 
send with function management header ($$SENDNF) 
system-supplied format 7-4, 7-6 


send with invite (S$$SEND) system-supplied format 7-4, 


7-6 
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sending 
data 
illustration 3-9 
using DDS keywords 6-3 
using system-supplied formats 7-4 
file members to a System/36 E-2 
negative-response 7-11 
to a System/36 E-6 
sense data format 7-12 
session 
acquiring 3-4, 3-14 
description 3-5 
end-of-session 
considerations 8-4 
function 7-18 
ending 
communications 6-18 
description 3-11 
example 3-10, 3-12 
sessions 3-11 
system-supplied formats 7-19 
using release operation, example 3-11 
establishing, example 3-4 
general examples 6-1 
multiple 
description 3-13, 11-25 
example 10-25 
example overview 10-2, 11-2 
levels 3-17 
source program 9-10, 10-32 
target program 9-24, 10-65 
transactions 3-12 
remotely starting 3-16 
source 5-2 
starting 
by remote program start request 3-16 
description 3-5 
example 3-12 
sequence diagrams 3-16 
target 5-3 
session attribute 
identifying 4-8 
overriding 4-8 
SNA 3270 program interface 
definition 2-2 
SNA MSRJ (non-ICF communications) 2-3 
SNUF (Systems Network Architecture upline facility) 
introduction 2-2 
VRYCFG (Vary Configuration) command 3-3, 3-12 
source 
program 3-6, 3-14 
sessions 5-2 
system 5-18 
source program 
batch transfer 10-5 
definition 3-6 


source program (continued) 
example 10-32, 10-37 
spooled trace record 12-3 
Start Mode (STRMOD) command 3-3 
Start Prestart Jobs (STRPJ) command 8-8 
Start Service Job (STRSRVJOB) command 12-1 
starting remote programs 3-4, 3-6 
status, configuration B-3 
STRMOD (Start Mode) command 3-3 
STRPJ (Start Prestart Jobs) command 8-8 
STRSRVJOB (Start Service Job) command 12-1 
SUBDEV (subdevice) keyword 6-4 
subdevice (SUBDEV) keyword 6-4 
subsystem description 
prestart job 
description 8-8 
QBASE 8-5 
QCMN_ 8-5 
support 
additional programming 2-5 
COBOL programming language 2-5 
ILE RPG/400 programming language 2-5 
synchronization level (SYNLVL) keyword 6-2 
synchronization level specification 6-2 
synchronous data link control (SDLC) 
definition 2-3 
SYNLVL (synchronization level) keyword 6-2 
system 
error Classification B-1 
messages B-1 
operating 1-1 
source 5-18 
target 5-19 
system-supplied format 
$$CANL (cancel with invite) 7-6, 7-10 
$$CANLNI (cancel) 7-10 
$$CNLINV (cancel-invite operation) 7-16 
$$EOS (end-of-session function) 7-19 
$$EVOK (evoke with invite) 7-2 
$$EVOKET (evoke with detach) 7-2, 7-17 
$$EVOKNI (evoke) 7-2 
$$FAIL (fail) 7-8 
$$NRSP (negative-response with invite) 7-6, 7-11 
$$NRSPNI (negative-response) 7-11 
$$POSRSP (positive-response) 7-13 
$$RCD (request-to-write-with-invite) 7-6 
$$RCD (request-to-write) 7-13 
$$SEND (send with invite) 7-4, 7-6 
$$SENDE (send with end-of-group) 7-4, 7-11 
$$SENDET (send with detach) 7-4, 7-17 
$$SENDFM (send with function-management-header and 
invite) 7-4, 7-6 
$$SENDNF (send with 
function-management-header) 7-4 
$$SENDNI (send) 7-4 
$$TIMER (timer) 7-7 


system-supplied format (continued) 
additional formats 7-13 
cancel ($$CANLNI) 7-10 
cancel with invite (S$CANL) 7-6, 7-10 
cancel-invite operation ($$CNLINV) 7-16 
communications functions 7-1 
end-of-session function ($$EOS) 7-19 
ending transaction 7-17 
evoke ($$EVOKNI) 7-2 
evoke with detach ($$EVOKET) 7-2, 7-17 
evoke with invite ($$EVOK) 7-2 
example target program start 7-2 
fail ($$FAIL) 7-8 
general description 7-1 
introduction 2-4 
map to DDS keywords 7-21 
negative-response (6$NRSPNI) 7-11 
negative-response with invite (S6NRSP) 7-6, 7-11 
positive-response (6$6POSRSP) 7-13 
problem notification formats 7-8 
receiving data 7-6 
request-to-write ($$RCD) 7-13 
request-to-write-with-invite (S$RCD) 7-6 
send ($$SENDNI) 7-4 
send with detach ($$SENDET) 7-4, 7-17 
send with end-of-group ($$SENDE) 7-4, 7-11 
send with function-management-header 

($$SENDNF) 7-4 
send with function-management-header and invite 
($$SENDFM) 7-4, 7-6 

send with invite (S$SEND) 7-4, 7-6 
sending data example 7-4 
starting on remote system 7-1 
support 7-20 
timer ($$TIMER) 7-7 

System/36 
AS/400 system retrieving files E-9 
load library members (QS36LOD) E-2 
procedure library members (QS36PRC) E-2 
retrieving a library member E-12 
retrieving objects E-2 
sending file members E-2 

Systems Network Architecture upline facility (SNUF) 
definition 2-2 
introduction 2-2 
VRYCFG (Vary Configuration) command 3-3, 3-12 


T 


target program 
definition 3-6 

target session 5-3 

target system 
definition [E-1 

TCP/IP (Transmission Control Protocol/Internet Protocol) 
See also TCP/IP Configuration and Reference, 

SC41-5420 
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TCP/IP (Transmission Control Protocol/Internet Protocol) 
(continued) 
non-ICF communications 2-3 
transport for APPC applications 2-2 
timer ($$TIMER) system-supplied format 
C/400 example 7-7 
COBOL/400 example 7-7 
format 7-7 
output field format 7-7 
purpose 7-7 
RPG/400 example 7-7 
use 7-7 
timer function 
description 6-8 
RPG/400 example 7-7 
TIMER keyword 
description 6-8 
difference 
from WAITRCD parameter 6-8 
timing ICF operation 6-8, 7-7 
TNSSYNLVL (transaction-synchronization-level) keyword 
description 6-5 
with detach function 6-17 
with invite function 6-8 
Trace ICF (TRCICF) display 12-1 
Trace Intersystem Communications Function (TRCICF) 
command 12-1 
trace record 
database file 12-4 
ending 12-5 
spooled 12-4 
starting 12-1 
stopping 12-2 
transaction 
communications 3-7 
description 3-7 
ending 
communications 3-10 
example 6-16 
with COBOL/400 WRITE statement 7-17 
more than one during a session 6-1 
receiving end of transaction 6-19 
starting 3-7 
transaction-synchronization-level (TNSSYNLVL) function 
with allow-write (ALWWRT) function 6-15 
transaction-synchronization-level (TNSSYNLVL) keyword 
description 6-5 
with detach function 6-17 
with invite function 6-8 
Transfer Control (TFRCTL) command 
program device entry overrides 4-10 
transferring 
files to and from AS/400 system E-3 
Transmission Control Protocol/Internet Protocol (TCP/IP) 
See also TCP/IP Configuration and Reference, 
$C41-5420 
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Transmission Control Protocol/Internet Protocol (TCP/IP) 
(continued) 
non-ICF communications 2-3 
transport for APPC applications 2-2 
TRCICF (Trace Intersystem Communications Function) 
command 12-1 
two-phase commit 
commit synchronization level 6-2 
DETACH (detach) function 6-17 
ICF general considerations 8-4 
prepare-for-commit (PRPCMT) function 6-5 
transaction-synchronization-level (TNSSYNLVL) 
function 6-5 
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user program error detection B-2 
using 

ICF file 3-3 

ICF operations 6-1 
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VARBUFMGT (variable-buffer-management) 
keyword 6-4 
Variable-Buffer-Management (VARBUFMGT) 
keyword 6-4 
variable-length data record (VARLEN) keyword 6-4 
VARLEN (variable-length data record) keyword 6-4 
Vary Configuration (VRYCFG) command 3-3 
varying on 
communications configurations 3-3 
VRYCFG (Vary Configuration) command 3-3 
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wait file (WAITFILE) parameter 4-5 
wait intervals 
responses 5-13 
specifying maximum 5-12 
WAITFILE (maximum file wait time) parameter 4-5 
WAITRCD (maximum record wait time) parameter 
description 4-5 
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use 4-5 
values 

general 4-5 


using read-from-invited-program-devices 4-5 
without using read-from-invited-program-devices 4-5 
Work with Active Jobs (WRKACTJOB) command 12-5 
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command B-3 
Work with Job (WRKJOB) command 12-5 


write operation 
language operations A-1 
sending data (COBOL/400 programming language) 7-4 
WRITE statement 
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COBOL/400 cancel operation example 7-11 
end-of-session function 7-18, 7-20 
ending 
sessions 7-19 
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negative-response operation examples 7-12 
request-to-write 7-13 
request-to-write examples 7-15 
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data 7-4 
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set timer (COBOL/400) function 7-7 
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programs 1-1 
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